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Foreword 

This Technical Specification has been produced by the 3 rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 



10 



ETSI TS 124 237 V9.4.0 (2010-10) 



1 Scope 

IP Multimedia (IM) Core Network (CN) subsystem Service Continuity (SC) provides the capability of continuing 
ongoing communication sessions with multiple media across different access networks or across different user 
equipments (UEs) under the control of the same subscriber. 

NOTE: When the communication session is transferred across different UEs, the session can be a collaborative 
session with controller and controllee UEs. In this version of the document, there can only be one 
controller UE but several controllee UEs in the collaborative session. 

The present document provides the protocol details for enabling IMS SC based on the Session Initiation protocol (SIP) 
and the Session Description Protocol (SDP) and the protocols of the 3GPP Circuit-Switched (CS) domain (e.g. CAP, 
MAP, ISUP, BICC and the NAS call control protocol for the CS access). 

The present document is applicable to User Equipment (UEs), Application Servers (AS), MSC Servers providing IMS 
Service Continuity capabilities and Emergency Access Transfer Function (EATF). 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) 

and Session Description Protocol (SDP); Stage 3". 

[3] 3GPP TS 24.228 Release 5: "Signalling flows for the IP multimedia call control based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[4] 3GPP TS 24.292: "IP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS); 

Stage 3". 

[5] 3GPP TS 24.216: "Communication continuity managed object". 

[6] 3GPP TS 29.328: "IP Multimedia Subsystem (IMS) Sh interface; Signalling flows and message 

contents". 

[7] 3GPP TS 29.329: "Sh interface based on the Diameter protocol; Protocol details". 

[8] 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network protocols; Stage 3". 

[9] 3GPP TS 23.237: "IP Multimedia subsystem (IMS) Service Continuity; Stage 2". 

[10] IETF RFC 3891: "The Session Initiation Protocol (SIP) "Replaces" Header". 

[II] IETF RFC 4538: "Request Authorization through Dialog Identification in the Session Initiation 
Protocol (SIP)". 

[12] 3GPP TS 23.003: "Numbering, addressing and identification". 

[13] IETF RFC 3515: "The Session Initiation Protocol (SIP) Refer Method". 
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[15] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

[16] IETF RFC 5012 (January 2008): "Requirements for Emergency Context Resolution with Internet 
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3 



Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
3GPP TR 21.905 [1]. 

Dynamic STI: An STI dynamically assigned by the SCC AS, representing the SIP dialog identifier (Call-ID header 
field and the values of tags in To and From header fields) and used for session transfer request when Gm service control 
is available. 

Inter UE Transfer SCC AS URI: A SIP URI which is a public service identity hosted by SCC AS and which is used 
in inter UE transfer procedures. 

Additional transferred session SCC AS URI: A SIP URI which is a public service identity hosted by SCC AS and 
which is used during PS-CS access transfer with the MSC Server assisted mid-call feature. 

Static STI: An STI configured in the SC UE either as a SIP URI or as an E.164 number in tel URI or SIP URI 
representation of tel URI. The static STI is used for CS-PS transfer when dynamic STI is unavailable. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.237 [9] apply: 

Access Leg 

Local Operating Environment 

Remote Leg 

Target Access Leg 

Source Access Leg 

Session Transfer Identifier (STI) 

Session Transfer Number (STN) 

Session Transfer Number for SR-VCC (STN-SR) 

Collaborative session 

Controllee UE 

Controller UE 

Inter-UE transfer 

Emergency Session Transfer Number for SR VCC(E-STN-SR) 
Correlation MSISDN 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.292 [4] apply: 



For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.003 [12] apply: 

IP Multimedia Routeing Number (IMRN) 
For the purposes of the present document, the following terms and definitions given in IETF RFC 5012 [16] apply: 

Emergency service URN 

For the purposes of the present document, the following terms and definitions given in IETF RFC 4353 [55] apply: 

Conference 
Conference URI 
Focus 
Participant 

For the purposes of the present document, the following terms and definitions given in IETF RFC 3264 [58] apply: 



CS call 
CS media 
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Directionality 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPP TR 21.905 [1]. 



EATF 


Emergency Access Transfer Function 


E-STN-SR 


Emergency Call Session Transfer Number - Single Radio 


E-SR-VCC 


Emergency Single Radio Voice Call Continuity 


IMRN 


IP Multimedia Routing Number 


SC 


Service Continuity 


sec 


Service Centralization and Continuity 


SM 


Session Management 


SR-VCC 


Single Radio VCC 


STI 


Session Transfer Identifier 


STN 


Session Transfer Number 


STN-SR 


Session Transfer Number - Single Radio 



4 Overview of IP Multimedia (IM) Core Network (CN) 
subsystem Service Continuity 

4.1 General 

In general, SC can be divided into two concepts: 

1 . providing the capability of transferring ongoing communication sessions with multiple media across different 
access networks. The main need for such continuity arises because user equipments (UEs) with multimedia 
capabilities can move across a multiplicity of different access networks; and 

2. providing the capability of transferring the communication sesions with multiple media across different UEs. 
The following procedures are provided within this document: 

procedures for registration in IM CN subsystem are specified in clause 6; 

- procedures for call origination are specified in clause 7; 

- procedures for call termination are specified in clause 8; 

- procedures for PS-CS access transfer are specified in clause 9; 

- procedures for PS-PS access transfer are specified in clause 10; 

- procedures for PS-PS access transfer in conjunction with PS-CS access transferare specified in clause 11; 

- procedures for PS-CS access transfer for Single Radio are specified in clause 12; 
procedures for media adding/deleting for access transfer are specified in clause 13; 
procedures for UE discovery for inter-UE transfer are specified in clause 14; 

- procedures for inter-UE transfer without establishment of collaborative session are specified in clause 15; 

- procedures for collaborative session establishment for inter-UE transfer are specified in clause 16; 

- procedures for media transfer within collaborative session for inter-UE transfer are specified in clause 17; 

- procedures for release of collaborative session for inter-UE transfer in clause 18; 
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- procedure for media adding/deleting within collaborative session for inter-UE transfer are specified in clause 19; 
and 

procedures for service continuity and MMTEL interactions are specified in clause 20. 
For a UE or an AS not supporting ICS procedures, PS-CS access transfer procedures enable transfer of 

- one active full-duplex speech or speech/video session; and 

- up to one active and up to one inactive active full-duplex speech or speech/video session when the MSC Server 
assisted mid-call feature is supported. 

Inter-UE transfer procedures are not limited by amount of established sessions. 

4.2 Underlying network capabilities 

SC assumes the use of a number of underlying network capabilities: 

1) provision by the home network operator of SCC AS on the IM CN subsystem, as specified in 
3GPPTS 24.229 [2]; 

2) if ICS is used, the network capabilities as specified in 3GPP TS 24.292 [4]; 

4.3 URI and address assignments 

In order to support SC to a subscriber, the following URI and address assignments are assumed: 

a) in this version of the document, the SC UE for access transfer will be configured with a static STI, in accordance 
with subclause 5.11 in 3GPP TS 24.216 [5]; a static STN in accordance with subclause 5.12 in 

3GPP TS 24.216 [5]. The static STI is used by the SC UE to perform CS to PS access transfer when no 
dynamically assigned STI is provided to the UE over the CS domain (e.g. when the SC UE does not support ICS 
capabilities as defined in 3GPP TS 24.292 [4]). The static STN is used by the SC UE to perform PS to CS access 
transfer when no service control signalling path as specified in 3GPP TS 24.292 [4] is available. 

b) the SC UE will be configured to be reachable in both the IM CN subsystem and the CS domain by one or more 
public telecommunication numbers which should be correlated between the CS domain and IM CN subsystem. 
Either: 

this public telecommunication number can be the DN (e.g. MSISDN) used in the CS domain and (in 
international form) comprise part of the implicit registration set associated with that SC UE in the IM CN 
subsystem; or 

- the SCC AS can be configured to provide a functional relationship between separate numbers providing each 
of these identities in the CS domain and the IM CN subsystem, respectively. 

c) in this version of the document, the SC UE for inter-UE transfer will be configured with an Inter UE Transfer 
SCC AS URI. The Inter UE Transfer SCC AS URI is used in the inter UE transfer procedures. 



5 Functional entities 

5.1 Introduction 

This clause associates the functional entities with the SC roles described in the stage 2 architecture document (see 
3GPPTS 23.237 [9]). 

5.2 User Equipment (UE) 

UE can be compliant with: 
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- both the access transfer and the inter-UE transfer; 

- the access transfer; or 

- the inter-UE transfer 
in this document. 

If the SC UE supports the Controller UE procedures for IUT transfer then the SC UE may include the g.3gpp.iut- 
controller media feature tag as described in annex C in the Contact header of SIP requests and SIP responses. 

To be compliant with access transfer in this document, a UE shall implement the role of an SC UE according to 
subclause 6A,2, subclause 6.2, subclause 7.2, subclause 8.2, subclause 9.2, subclause 10.2, subclause 11.2, 
subclause 12.2, subclause 13.2 and subclause 20.1. 

To be compliant with inter-UE transfer in this document, a UE shall implement the role of an SC UE: 

- by following the procedures specified in 3GPP TS 24.229 [2] for registration of the UE in the IM CN subsystem; 
and 

- according to subclause 14.2, subclause 15.2, subclause 16.2, subclause 17.2, subclause 18.2, subclause 19.2, 
subclause 20.2 and subclause 21.2. 

NOTE: In the inter-UE transfer, a session can be collaborative session where there are one controller UE and 

severeal controllee UEs. The controllee UE can be a legacy UE and does not have be compliant with the 
above subclauses. 

5.3 Application Server (AS) 

AS can be compliant with: 

- both the access transfer and the inter-UE transfer; 

- the access transfer; or 

- the inter-UE transfer 
in this document. 

To be compliant with access transfer in this document, an AS shall implement the role of an SCC AS according to 
subclause 6.3, subclause 7.3, subclause 8.3, subclause 9.3, subclause 10.3, subclause 11.3, subclause 12.3, 
subclause 13.3 and subclause 20.1. 

To be compliant with inter-UE transfer in this document, an AS shall implement the role of an SCC AS according to 
subclause 14.3, subclause 15.3, subclause 16.3, subclause 17.3, subclause 18.3, subclause 19.3, subclause 20.2 and 
subclause 21.3. 

5.4 MSC Server 

An MSC Server can be compliant with SR VCC session transfer procedures as described in this document. 

In order to be compliant with SRVCC session transfer procedures as described in this document, an MSC server using 
SIP interface to initiate the session transfer shall provide the UA role as defined for a MGCF in annex A of 
3GPP TS 24.229 [1 1] and the role of an MSC server enhanced for SRVCC using SIP interface as described in 
subclause 12.6. 

An MSC Server can be compliant with the access transfer procedures for the MSC server assisted mid-call feature as 
described in this document. 

In order to be compliant with the access transfer procedures for the MSC server assisted mid-call feature as described in 
this document, the MSC server shall provide the role of an MSC server enhanced for ICS as described in subclause 6.4, 
subclause 9.4 and subclause 12.4. 
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5.5 EATF 

To be compliant with access transfer in this document, the EATF shall act as B2BUA and: 

extract charging information as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.1.2; 

- identify the served user as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.1.3A.2; 

map the message header fields from a SIP message received in one dialog to related SIP message sent in the 
correlated dialog managed by EATF as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; 

pass signalling elements as specified for an AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; 

- handle P-Charging-Vector header as specified for an routeing AS in 3GPP TS 24.229 [2], subclause 5.7.5.1; and 

- implement the role of an EATF according to subclause 7.4 and subclause 12.5. 

6 Roles for registration in the IM CN subsystem for 
service continuity 

6.1 Introduction 

Void. 

6.2 SC UE 

Prior to performing IMS registration, if the SC UE supports ICS capabilities as defined in 3 GPP TS 24.292 [4], the SC 
UE shall check that IMS service continuity using ICS is enabled. An indication that SC using ICS is enabled or disabled 
can be found in the ICS MO ICS_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [23]). 

The SC UE shall follow the procedures specified in 3GPP TS 24.229 [2] for registration of the UE in the IM CN 
subsystem. 

If SC using ICS is enabled then prior to making use of ICS procedures, the SC UE shall follow the procedures specified 
in 3GPP TS 24.292 [4] for registration of the ICS UE in the IM CN subsystem. 

If the SC UE supports the Controller UE procedures for IUT transfer then the SC UE shall include the g.3gpp.iut- 
controller media feature tag as described in annex C in the Contact header field of the SIP REGISTER request. 

6.3 SCC AS 

The SCC AS can obtain registration state information that it needs to implement SCC specific requirements from: 

a) any received third-party SIP REGISTER request (e.g. including information contained in the body of the third- 
party SIP REGISTER request) as specified in 3GPP TS 24.229 [2]; 

b) any received reg event package as specified in 3GPP TS 24.229 [2]; or 

c) the Sh interface as specified in 3GPP TS 29.328 [6] and 3GPP TS 29.329 [7]. 

NOTE: Obtaining registration state information from HSS using Sh interface does not allow the SCC AS to know 
the capabilities supported by the user registered UE(s), including the used IP-CAN(s). 

When the SCC AS obtains the registration state information including an Correlation MSISDN using one of the above 
procedures, the SCC AS shall determine if the registration state information is associated with ongoing CS call by 
matching the Correlation MSISDN against the: 

a) tel URI in the P-Asserted-Identity header field or associated with the received IMRN when the SIP INVITE 
request was due to static STN, where the SIP INVITE request was stored according to subclause 7.3.1; or 
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b) tel URI in the Request-URI when the SIP INVITE request was due to processing unregistered filter criteria, 
where the SIP INVITE request was stored according to subclause 7.3.1. 

If the registration state information is associated with an ongoing call the contents of the registration state information 
shall be bound to the ongoing CS call session identifier. 

6.4 MSC server 

If MSC server supports the MSC server assisted mid-call feature, the MSC server shall behave as an MSC server 
enhanced for ICS as specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4] with following additions: 

- include the g.3gpp. mid-call media feature tag as described in annex C in the Contact header field of the SIP 
REGISTER request. 



6A Roles for General Capabilities 
6A.1 Introduction 

This clause describes the general roles for each functional entity as specified. 

6A.2 UE roles 

The SC UE may receive the operator policy via OMA Device Management, see 3 GPP TS 24.216 [5]. When the SC UE 
receives the operator policy, for each session to be transferred, it shall take the operator policy into account when 
deciding to perform the following: 

- selecting the access for initiating the transfer; 

- determining whether to transfer full or partial media during PS-PS transfer; or 

determining whether to add or remove media during the PS-PS transfer. 

If the SC UE is configured with the operator policy (e.g. via OMA Device Management as described in 

3GPP TS 24.216 [5]) then, for each media or group of media contained in the MediaorGroup node, the SC UE shall: 

1) restrict originating sessions and session transfer towards the access networks contained in the 
RestrictedAccessNetworkType node; 

2) consider the list of access networks contained in the PreferredAccessNetworks node in the order of priority from 
the access networks such that, when available, the highest priority access network can be used for originating 
sessions and session transfer procedures; 

3) if a new access network gets available- transfer media components to a higher priority target network than the 
current access network based on the value contained in the SC_media_transfer node value. If the 
SC_media_transfer node value is: 

"shall" the UE shall start a session transfer according to the home operator' s list of preferred access networks 
contained in the PreferredAccessNetworks node; 

"should" the UE is recommended to start session transfer according to the home operator' s list of preferred 
access networks contained in the PreferredAccessNetworks node. The UE can evaluate if session transfer is 
possible and desirable after having taken into account the Local Operating Environment Information; and 

"may" the UE can decide whether or not to start session transfer in accordance with user preferences if 
configured in the UE. The UE can evaluate if session transfer is possible and desirable after having taken into 
account the Local Operating Environment Information. If user preferences are not configured, the UE can 
evaluate the home operator' s list of preferred access networks contained in the PreferredAccessNetworks 
node; and 
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4) decide whether to keep or drop non transferable media components in the case of partial session transfer based 
on the SC_non_transferrable_media node value. 



7 Roles for call origination for service continuity 

7.1 Introduction 

This clause specifies the procedures for call origination, both where the SC UE is generating calls in the CS domain and 
where the SC UE is generating calls using the IM CN subsystem. Procedures are specified for the SC UE, the SCC AS 
and the EATF. 

7.2 SC UE 

7.2.1 General 

The SC UE shall support origination of IP multimedia sessions in the IM CN subsystem as specified in 

3GPP TS 24.229 [2]. If the SC UE supports the MSC server assisted mid-call feature, the SC UE shall include the 

g.3gpp. mid-call media feature tag as described in annex C in the Contact header field of the SIP INVITE request. 

The SC UE shall support origination of calls in the CS domain as specified in 3GPP TS 24.008 [8]. 

If SC using ICS is enabled then the procedures for call origination where the SC UE is initiating calls using CS media 
are identical to that for ICS UE specified in 3GPP TS 24.292 [4]. 

When originating an emergency call as specified in 3 GPP TS 24.229 [2] and if the SC UE has an IMEI, then the SC UE 
shall include the instance-id media feature tag as specified in IETF RFC 5626 [22] with value based on the IMEI as 
defined in 3GPP TS 23.003 [12] in the Contact header field of the SIP INVITE request. 

7.2.2 Additional procedures with MSC server assisted mid-call feature 

Upon receiving a SIP 2xx response to the SIP INVITE request, if: 

1. the SC UE supports the MSC server assisted mid-call feature; 

2. the g.3gpp. mid-call media feature tag is included in the Contact header field received during session 
establishment; 

3. the remote UE is a conference focus; and 

NOTE: conference focus includes the isfocus media feature tag specified in IETF RFC 3840 [53] in own Contact 
header field when establishing a session. 

4. the session was created as result of the SC UE creating a conference; 

then the SC UE shall subscribe to the conference event package as specified in 3GPP TS 24.605 [31] and shall populate 
the Contact header field of the SUBSCRIBE request with the g.3gpp. mid-call media feature tag. 

If the subscription is accepted then the SC UE shall keep one subscription to the conference event package with own 
Contact header field containing the g.3gpp. mid-call media feature tag for each conference where the SC UE participates 
using procedures specified in 3GPP TS 24.605 [31]. 

7.3 SCC AS 

7.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call origination: 
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SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the origination procedures as specified in 3GPP TS 24.229 [2], and therefore distinguished 
by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header. In the 
procedures below, such requests are known as "SIP INVITE requests due to originating filter criteria". It is 
assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the request from 
the UE. 

The SCC AS shall store the SIP INVITE requests due to static STN (as defined in subclause 9.3.1) and the SIP INVITE 
requests due to originating filter criteria, at least until their sessions are terminated. 

The SCC AS needs to distinguish between the following initial requests to provide specific functionality related to 
obtaining conference participants: 

- SIP SUBSCRIBE requests with an Event header field containing "conference" and with the Contact header field 
containing the g.3gpp. mid-call media feature tag routed to the SCC AS over the ISC interface as a result of 
processing initial filter criteria at the S-CSCF according to the originating procedures as specified in 
3GPP TS 24.229 [2]. In the procedures below, such requests are known as "SIP SUBSCRIBE requests to 
conference event package". 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

7.3.2 Call origination procedures at the SCC AS 

When the SCC AS receives a SIP INVITE request due to originating filter criteria, the SCC AS shall follow the SCC 
AS roles for call origination procedures specified in 3GPP TS 24.292 [4]. 

If: 

1 . the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; 

2. the g.3gpp. mid-call media feature tag as described in annex C is included in the Contact header field of the SIP 
INVITE request due to originating filter criteria; and 

3. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature; 

NOTE: SCC AS can identify the network where the UE is registered based on the P-Visited-Network-Id header 
field and the P-Access-Network-Info header field of the SIP REGISTER request. 

then the SCC AS shall include the g.3gpp. mid-call media feature tag as described in annex C in the Contact header field 
of the SIP 2xx response to the SIP INVITE request due to originating filter criteria. 

If the SCC AS supports the MSC Server assisted mid-call feature according to operator policy, the SCC AS shall 
remove the g.3gpp. mid-call media feature tag as described in annex C from the SIP INVITE request due to originating 
filter criteria before forwarding the SIP INVITE request towards the remote UE. 

7.3.3 Subscription related procedures in the SCC AS 

When the SCC AS receives a SIP SUBSCRIBE request to conference event package, if the SCC AS supports the MSC 
Server assisted mid-call feature according to operator policy and if SCC AS determines that the subscription is related 
to an anchored session then the SCC AS shall ensure that it remains on the path for future requests in the dialog before 
forwarding the request. 

NOTE: ASs acting as Routeing B2BUA and record-routing ASs acting as SIP proxy remain on the path for future 
requests in the dialog. 

When the SCC AS receives SIP 2xx response to the SIP NOTIFY request with conference information, the SCC AS 
shall update the stored conference information based on the SIP NOTIFY request content and forward the SIP 2xx 
response in any manner conformant with 3GPP TS 24.229 [2]. 

The SCC AS shall determine that a subscription to conference event package is related to a session if: 
1 . the session was originated by served SC UE; 
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2. remote UE of the session is a conference focus; 

3. the P-Asserted-Identity header field of the served SC UE used at the establishment of the session is the same as 
the P-Asserted-Identity header field of the served SC UE used at the subscription; and 

4. the Contact or the P-Asserted-Identity header field provided to the served SC UE at the establishment of the 
session is the same as the Request-URI used at the subscription; 

If multiple such subscriptions exist, the SCC AS shall select the subscription that originates from the same device as the 
session. 

7.4 EATF 

7.4.1 Distinction of requests sent to the EATF 

The EATF needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call origination: 

SIP INVITE request including a request URI that contains an emergency service URN, i.e. a service URN with a 
top-level service type of "sos" as specified in IETF RFC 5031 [17]. In the procedures below, such requests are 
known as "SIP INVITE requests due to emergency service URN". 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

7.4.2 Call origination procedures at the EATF 

When the EATF receives a SIP INVITE requests due to emergency service URN, the EATF shall store the SIP INVITE 
request until the session is terminated, anchor the session and act as specified for a routeing B2BUA in 
3GPP TS 24.229 [2], subclause 5.7.5.2.1. 



8 Roles for call termination for service continuity 

8.1 Introduction 

This clause specifies the procedures for call termination, both where the SC UE is receiving calls in the CS domain and 
where the SC UE is receiving calls using the IM CN subsystem. Procedures are specified for the SC UE and the 
SCC AS. 

8.2 SC UE 

The SC UE shall support termination of multimedia sessions in the IM CN subsystem as specified in 
3GPP TS 24.229 [2] with the following clarifications: 

1) If the SC UE supports the MSC server assisted mid-call feature, and the receiving SIP INVITE request includes 
g.3gpp. mid-call media feature tag as described in annex C in the Contact header field, the SC UE shall include 
the g.3gpp. mid-call media feature tag as described in annex C in the Contact header field of the SIP 2xx response 
to the SIP INVITE request. 

2) If the SC UE not supporting ICS or supporting ICS but with ICS Capabilities disabled receives a SIP INVITE 
request containing a SDP offer which includes audio media with speech codecs transported using an IP bearer, 
and: 

NOTE: An indication that an SC UE with ICS capabilities has its ICS capabilities enabled or disabled can be 
found in the ICS MO ICS_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [23]). 

a) if the SC UE sends the response to the SIP INVITE request over GERAN; 
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b) if the SC UE sends the response to the SIP INVITE request over E-UTRAN or UTRAN, and the IMS VoPS 
indicator indicates that voice is not supported; or 

c) if the SC UE sends the response to the SIP INVITE request over an access network other than E-UTRAN, 
UTRAN and GERAN, and the access network does not support the offered audio media with speech codecs 
transported using an IP bearer; 

then the SC UE shall send back a SIP 488 (Not Acceptable Here) response without a message body 

The SC UE not supporting ICS or with ICS Capabilities disabled shall support termination of calls in the CS domain as 
specified in 3GPP TS 24.008 [8]. 

An SC UE that supports ICS and has ICS capabilities enabled shall follow the call termination procedures as specified 
in3GPPTS24.292[4]. 

8.3 SCC AS 

8.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call termination: 

- SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the termination procedures as specified in 3GPP TS 24.229 [2], and therefore distinguished 
by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header field. In the 
procedures below, such requests are known as "SIP INVITE requests due to terminating filter criteria". It is 
assumed that the SCC AS is the last AS that the S-CSCF forwards the request to. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2] . 

8.3.2 Call termination procedures in the SCC AS 

When the SCC AS receives a SIP INVITE request due to terminating filter criteria, the SCC AS shall follow the SCC 
AS roles for call termination procedures specified in 3GPP TS 24.292 [4]. 

If: 

1 . the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; and 

2. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature; 

then the SCC AS shall include the g.3gpp. mid-call media feature tag as described in annex C in the Contact header field 
of the SIP INVITE request due to terminating filter criteria. 

If the SCC AS supports the MSC Server assisted mid-call feature according to operator policy, the SCC AS shall 
remove the g.3gpp. mid-call media feature tag as described in annex C from the SIP 2xx response to the SIP INVITE 
request due to terminating filter criteria before forwarding the SIP 2xx response towards the remote UE. 



9 Roles for PS-CS access transfer 



9.1 Introduction 

For a UE or an AS not supporting ICS procedures, PS-CS access transfer procedures enable transfer of 
- one active full-duplex speech or speech/video session; and 
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up to one active and up to one inactive active full-duplex speech or speech/video session when the MSC Server 
assisted mid-call feature is supported. 

9.1 A Additional procedures with MSC Server assisted mid-call 

feature 

When a conference is transferred to CS domain using MSC Server assisted mid-call feature, the participants are 
extracted from the stored conference information as follows: 

1. at maximum first 5 participants listed in the <user> elements: 

a. included in <users> parent element included in <conference-info> root element of the conference 
information; 

b. containing at least one <endpoint> child element with <status> child element containing one of the states 
"connected", "on-hold", "muted-via-focus", "pending", "alerting", "dialing-in" or "dialing-out"; and 

c where "entity" attribute is different than the URI in the P-Asserted-Identity header field of the served SC UE 
used at the subscription. 

9.2 SC UE 

9.2.1 SC UE procedures for PS to CS access transfer 

If SC UE uses ICS capabilities, this subclause applies for IMS sessions containing speech media component only, 
otherwise subclause 11.2.1.2 applies. 

The SC UE may be engaged in one or more ongoing sessions at the time of initiating access transfer. By an ongoing 
session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session 
has been sent or received. 

If SC using ICS is enabled then if the SC UE is using Gm, then for each session to be transferred and starting with the 
active session, the SC UE shall send a SIP INVITE request to the SCC AS according to the ICS UE using Gm 
procedures for call origination as specified in 3GPP TS 24.292 [4]. The SC UE shall populate the SIP INVITE request 
as specified for PS-PS access transfer with full media transfer in subclause 10.2.1 (including the STI of the dialog to be 
transferred) with the following exceptions: 

- The SC UE shall indicate in the SIP INVITE request that the speech media is using CS bearer with its 
corresponding media description. 

- Upon receiving the PSI DN from the SCC AS, the SC UE shall follow the procedures for call origination for ICS 
UE using Gm in 3GPP TS 24.292 [4] to set up the CS bearer. 

If the SC UE is not using ICS capabilities and if the SC UE does not apply the MSC Server assisted mid-call feature as 
specified in subclause 9.2. 1A, the SC UE shall: 

a) if more than one full-duplex speech session exists, first initiate the release of all the ongoing full-duplex speech 
sessions except the session with active full-duplex speech component that was most recently made active and 
then the SC UE shall transfer the remaining ongoing active full-duplex speech session. 

When transferring the session(s) not using ICS capabilities, the SC UE shall send, a CC SETUP message as specified 
in 3GPP TS 24.008 [8], to the SCC AS to set up a call over the CS domain. When sending CC SETUP message, the SC 
UE shall populate the CC SETUP message as follows: 

1) the called party BCD number information element set to the static STN; and 

2) Type Of Number set to "International" and Numbering Plan Indicator set to "E. 164" .in the Called Party BCD 
Number information element. 

If the SC UE receives a release message to the CC SETUP message sent, then PS-CS access transfer has not completed 
successfully and the call will continue in the Source Access Leg. 
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9.2.1 A SC UE procedures for PS to CS access transfer with MSC server 
assisted mid-call feature 

The SC UE shall apply the MSC Server assisted mid-call feature when transferring the session not using ICS 
capabilities if: 

1. the SC UE supports the MSC Server assisted mid-call feature; and 

2. one of the following is true: 

A. there is at least one ongoing active full-duplex speech session and the Contact header field received during 
the establishment of the ongoing active full-duplex speech session which has been most recently made active 
includes the g.3gpp. mid-call media feature tag as described in annex C; or 

B. there is no ongoing active full-duplex speech session and the Contact header field received during the 
establishment of the ongoing inactive full-duplex speech session which became inactive most recently 
includes the g.3gpp. mid-call media feature tag as described in annex C. 

When the SC UE applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.2.1, and before sending a message to set up a call over the CS domain, the SC UE shall: 

1 . if there are two or more ongoing active full-duplex speech sessions: 

A. initiate the release of all the ongoing full-duplex speech sessions except two that were most recently made 
active; 

B. initiate the session modification of the ongoing full-duplex speech session that was made active less recently 
and offer the full-duplex speech component with "sendonly" or "inactive" directionality; and 

C. transfer two remaining ongoing full-duplex speech sessions; 

NOTE 1 : When active and inactive ongoing full-duplex speech sessions exist, one CC SETUP message transfers 
both sessions. 

2. if there are one ongoing active full-duplex speech session and one or more ongoing inactive full-duplex speech 
session, 

A. initiate the release of all the ongoing inactive full-duplex speech sessions except the one which became 
inactive most recently; and 

B. transfer two remaining ongoing full-duplex speech sessions; 

NOTE 2: When active and inactive ongoing full-duplex speech sessions exist, one CC SETUP message transfers 
both sessions. 

3. if there is one ongoing active full-duplex speech session and no ongoing inactive full-duplex speech session, 
transfer the ongoing full-duplex speech session; and 

4. if there is no ongoing active full-duplex speech session and there is one or more ongoing inactive full-duplex 
speech sessions: 

A. initiate the release of all the ongoing inactive full-duplex speech sessions except the one which became 
inactive most recently; and 

C. transfer the ongoing full-duplex speech session. 

NOTE 3: The ongoing inactive full-duplex speech sessions is transferred to a held CS call. 

The SC UE shall associate the additional transferred session with CS call with transaction identifier calculated as in the 
table 9.2.1A-1 and TI flag value as in mobile originated call. 

Table 9.2.1 A- 1 : held session transaction identifier calculation formula 



transaction identifier of the additional transferred session> = (1 + <transaction identifier 
of the CS call established by the SETUP message>) modulo 7 
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If: 

1. the SC UE has a subscription as described in subclause 7.2.2 for the active full-duplex speech session; or 

2. the active full-duplex speech session does not exist and the SC UE has a subscription as described in 
subclause 7.2.2 for the inactive full-duplex speech session; 

then the SC UE shall associate the participants extracted in subclause 9.1 A with transaction identifiers calculated as in 
the table 9.2.1A-2 and with TI flag of the session. The offsets 0, 2, 3, 4, 5 are assigned to the participants in their order 
in the list of the extracted participants. 

Table 9.2.1 A-2: transaction identifier assignment for participants 

<transaction identifier of participants = ( <transaction identifier of the conference> + 
<offset of participants modulo 7 



If 

1 . the active full-duplex speech session exists and the SC UE does not have a subscription as described in 
subclause 7.2.2 for the active full-duplex speech session; and 

2. the SC UE has a subscription as described in subclause 7.2.2 for the additional transferred session; 

then the SC UE shall associate the participants extracted in subclause 9.1 A with transaction identifiers calculated as in 
the table 9.2.1A-2 and with TI flag of the additional transferred session. The offsets 0, 1, 2, 3, 4 are assigned to the 
participants in their order in the list of the extracted participants. 

The SC UE shall consider session with speech: 

which has "sendonly" or "inactive" directionality as inactive; and 

- which has "recvonly" or "sendrecv" directionality as active; 

in this subclause and in the referenced subclauses. 

9.2.1 B SC UE procedures for PS to CS access transfer with MSC server 

assisted mid-call feature for speech and video session 

When PS to CS access transfer occurs, with a speech and video session and another speech session using PS media in 
the SC UE, the SC UE applies the MSC Server assisted mid-call feature according to the procedures described in 
subclause 9.2. 1A with the following additions: 

if the SC UE supports SCUDIF feature, and the speech and video session is active and speech session is inactive 
the SC UE shall transfer the active speech and video session as specified in subclause 9.2.1, and indicate the 
support of SCUDIF in the CC SETUP message as specified in 3GPP TS 24.008 [8], with multimedia bearer 
capability preferred for the current active session; and 

if the SC UE supports SCUDIF feature, and the speech and video session is inactive and speech session is active, 
the SC UE shall transfer the speech session as specified in subclause 9.2.1, and indicate the support of SCUDIF 
in the CC SETUP message as specified in 3GPP TS 24.008 [8], with speech bearer capability preferred for the 
current active session. 

NOTE: After successful transfer of the speech and video session and another speech session from PS to CS, the 

UE can switch between the two sessions by holding/releasing the active session and resuming the inactive 
session as specified in 3GPP TS 24.008 [8], with the addition that the UE can initiate the in-call 
modification or Redial procedures as specified in 3GPP TS 24.008 [8] to change the shared CS bearer of 
the two sessions from speech to multimedia, or vice versa. 

9.2.2 SC UE procedures for CS to PS access transfer 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a CS call for which the CS call setup procedure is complete, e.g. a CC CONNECT message has been sent or 
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received as described in 3GPP TS 24.008 [8] or a call for which the SIP 2xx response for the initial SIP INVITE request 
to establish this session has been sent or received. 

If not already registered in the IM CN subsystem, the SC UE shall follow the procedures specified in subclause 6.2 to 
perform registration over the Target Access Leg before performing CS to PS access transfer. 

If SC using ICS is enabled then if the original sessions are established using ICS capabilities as defined in 
3GPP TS 24.292 [4], then for each session to be transferred and starting with the active session, the SC UE shall send a 
SIP INVITE request to the SCC AS in accordance with the UE procedures specified in 3GPP TS 24.229 [2]. The SC 
UE shall populate the SIP INVITE request as specified for PS-PS access transfer with full media transfer in 
subclause 10.2.1. 

If the original sessions are not established using ICS capabilities and the SC UE does not support the MSC Server 
assisted mid-call feature as described in subclause 9.2.3, subject to the SC_non_transferrable_media node value in the 
Communication Continuity MO (see subclause 5.27 in 3GPP TS 24.216 [5]) the SC UE shall: 

a) if more than one full-duplex speech session exists, first initiate the release of all the ongoing sessions that are 
currently not active with the UE procedures specified in 3GPP TS 24.083 [43] and then the SC UE shall transfer 
the remaining ongoing active full-duplex speech session. 

When transferring the session(s) not using ICS capabilities, the SC UE shall send a SIP INVITE request to the SCC AS 
in accordance with the UE procedures specified in 3GPP TS 24.229 [2] . The SC UE shall populate the SIP INVITE 
request as follows: 

1) the Request-URI set to the static STI; and 

2) include in the Contact header field a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2], if a 
GRUU was received at registration. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the CS domain. 

When the SC UE receives a CS call release message, e.g. CC DISCONNECT message as specified in 

3GPP TS 24.008 [8], from the network, the SC UE shall comply with network initiated call release procedures to 

release the CS bearer. 

9.2.3 SC UE procedures for CS to PS access transfer with MSC server 
assisted mid-call feature 

When the SC UE supports the MSC Server assisted mid-call feature, the SC UE shall populate the SIP INVITE request 
for transferring the session not using ICS capabilities as follows in addition to the procedures described in 
subclause 9.2.2: 

1. the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; 

2. the Accept header field containing the MIME type as specified in annex D.1.3; and 

3. include in the Contact header field the g.3gpp. mid-call media feature tag as described in annex C. 

NOTE 1 : If the original sessions are not established using ICS capabilities as defined in 3GPP TS 24.292 [4] and 
the SCC AS and the SC UE support the MSC Server assisted mid-call feature, up to one active and up to 
one inactive full-duplex speech session can be transferred. 

Upon receiving a SIP REFER request within the SIP session established by the SIP INVITE request for transferring the 
session not using ICS capabilities: 

1. with the Refer-Sub header field containing "false" value; 

2. with the Supported header field containing "norefersub" value; 

3. with the Target-Dialog URI header field in the URI of the Refer-To header field; 

4. where the g.3gpp. mid-call media feature tag as specified in annex C was included in the Contact header field of 
the SIP 2xx response to the SIP INVITE request; and 
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5. containing a MIME body of MIME type specified in the annex D. 1 .3; 
and if the SC UE supports the MSC Server assisted mid-call feature, then the SC UE shall: 

1. handle the SIP REFER request as specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and 
IETF RFC 4488 [20]; and 

2. send a SIP INVITE request for an additional inactive session in accordance with the procedures specified in 
3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The SC UE shall populate the SIP INVITE request as follows: 

A. header fields which were included as URI header fields in the URI in the Refer-To header field of the 
received SIP REFER request as specified in IETF RFC 3261 [19] except the "body" URI header field; 

B. include in the Contact header field: 

a. a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

b. the g.3gpp. mid-call media feature tag as described in annex C; and 

C. the SDP offer with: 

a. the same amount of the media descriptions as in the "body" URI header field in the URI in the Refer-To 
header field of the received SIP REFER request; 

b. each "m=" line having the same media type as the corresponding "m=" line in the "body" URI header 
field in the URI in the Refer-To header field of the received SIP REFER request; 

c. port set to zero value in each "m=" line whose corresponding "m=" line in the "body" URI header field in 
the URI in the Refer-To header field of the received SIP REFER request has port with zero value; and 

d. media directionality as in the "body" URI header field in the URI in the Refer-To header field of the 
received SIP REFER request. 

NOTE 2: port can be sent to zero or non zero value for the offered "m=" line whose corresponding "m=" line in the 
"body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has 
port with nonzero value. 

Upon receiving a SIP 2xx response for the SIP INVITE request, then the SC UE shall proceed as specified in 
subclause 7.2.2. 

The SC UE shall consider session with speech: 

- which has "sendonly" or "inactive" directionality as inactive; and 

- which has "recvonly" or "sendrecv" directionality as active; 
in this subclause and in the referenced subclauses. 

9.3 SCC AS 

9.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field and not containing Inter UE Transfer SCC AS URI in the Request- 
URL In the procedures below, such requests are known as "SIP INVITE requests due to STI". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URL In the procedures 
below, such requests are known as "SIP INVITE requests due to static STI". 
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- SIP INVITE requests routed to the SCC AS containing either a static STN, a STN-SR or an IMRN (as 
described in 3GPP TS 24.292 [4]) in the Request-URL In the procedures below, such requests are known as 
"SIP INVITE requests due to static STN". 

NOTE 1 : The media streams that need to be transferred are identified using information described in the subsequent 
sections. 

NOTE 2: SIP INVITE requests routed to the SCC AS containing the additional transferred session SCC AS URI in 
the Request-URI which are used in the PS-CS access transfer with the MSC server assisted mid-call 
feature are handled by the PS-PS access transfer procedure as described in subclause 10.3. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

9.3.2 SCC AS procedures for PS to CS access transfer 

This subclause does not apply to reception of a SIP INVITE request due to STI with CS media and other kind of media 
or without CS media. 

When the SCC AS receives a SIP INVITE request due to STI with CS media only on the Target Access Leg, the SCC 
AS shall follow the procedures specified in subclause 10.3.2 with the following exceptions: 

- As the SIP INVITE request includes an active speech media component using CS bearer, then the SCC AS shall 
follow the procedures for SCC AS for service control over Gm in 3GPP TS 24.292 [4] to send the PSI DN to the 
SC UE and wait for the SC UE to set up CS bearer before sending SIP re-INVITE to the remote end. 

- The SCC AS shall correlate the STI with the allocated PSI DN in order to identify the remote leg to be updated. 

When the SCC AS receives SIP INVITE request due to static STN, the SCC AS shall associate the SIP INVITE request 
with an ongoing dialog supporting a session based on information associated with the received IMRN (as described in 
3GPP TS 24.292 [4]) or based on information from the SIP History-Info header field and P- Asserted header field and 
contact header field and send a SIP re-INVITE request towards the remote UE using the existing established dialog. By 
an ongoing dialog supporting a session, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE 
request has been sent or received. Multiple dialogs supporting a session associated with the same SC UE may have been 
anchored when the SCC AS receives a SIP INVITE request due to static STN. This can occur in the event that the UE 
does not succeed in releasing all dialogs supporting a session with inactive audio media or if the UE applies the MSC 
Server assisted mid-call feature. The identification of the associated dialog is subject to the following conditions: 

1 . if only one dialog supporting a session with active audio media exists for the user identified in the P-Asserted- 
Identity header field and a SIP 2xx response has been sent, then continue the session transfer with the dialog 
supporting a session with active audio media; 

2. if no dialogs supporting a session with active audio media exist for the user identified in the P-Asserted-Identity 
header field and a SIP 2xx response has been sent and the SCC AS does not apply the MSC Server assisted mid- 
call feature as specified in subclause 9.3.2A, then send a SIP 480 (Temporarily Unavailable) response to reject 
the SIP INVITE request relating to the session transfer; 

3. if more than one dialog supporting a session with active audio media exists for the user identified in the P- 
Asserted-Identity header field for which SIP 2xx responses have been sent, then the SCC AS shall perform 
session transfer procedures for the dialog that originates from the same device that initiated the received SIP 
INVITE request due to static STN. If more than one such dialogs exists from the same device, the SCC AS shall 
proceed with the next step in this list; and 

NOTE 1 : Whether the dialog originates from the same UE as the received SIP INVITE request is determined based 
on local information and information related to the correlation MSISDN or the GRUU of the originating 
user as determined via registration procedures as defined in subclause 6.3. 

4. if more than one dialog supporting a session exists for the user identified in the P-Asserted-Identity header field 
and exactly one dialog supporting a session with active audio media exists and a SIP 2xx response has been sent 
for that dialog, then: 

- if the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, then 
the SCC AS may release the dialogs supporting a session with inactive audio media and continue the session 
transfer procedures with the dialog supporting a session with active audio media; or 
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if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

5. if more than one dialog supporting a session with active audio media exist for the user identified in the P- 
Asserted-Identity header field and a SIP 2xx response has been sent for that dialog, then: 

- if the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, the 
SCC AS may release all dialogs supporting a session with audio media of the user identified in the P- 
Asserted-Identity header field for which a SIP 2xx response has been sent except the one with the active 
audio media that was most recently made active and continue the session transfer procedures; or 

- if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

Continuing the session transfer procedures, the SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote UE; and 

2) set the contact header field to the contact header field provided by the served UE at the creation of the dialog 
with the remote UE; and 

3) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to static STN, 
by following the rules of 3GPP TS 24.229 [2]. 

Upon receiving the SIP ACK request from the IM CN subsystem, then: 

if the source access leg contains only one audio media components the SCC AS shall initiate release of the 
source access leg by sending a SIP BYE request toward the S-CSCF for sending to the served SC UE; or 

- If the Source Access Leg contains media components other than audio media component, the SCC AS should 
send a SIP re-INVITE request to update the source access leg. 

9.3.2A SCC AS procedures for PS to CS access transfer with MSC server 
assisted mid-call feature 

The SCC AS shall apply the MSC Server assisted mid-call feature if: 

1. the Contact header field of the SIP INVITE request due to static STN includes the g.3gpp. mid-call media feature 
tag as specified in annex C; 

2. one of the following is true: 

A. at least one dialog supporting a session with active audio media exists for the user identified in the P- 
Asserted-Identity header field and the Contact header field provided by the SC UE at the establishment of the 
dialog supporting a session with active audio media which has been most recently made active includes the 
g.3gpp. mid-call media feature tag as described in annex C; or 

B. no dialog supporting a session with active audio media exists for the user identified in the P-Asserted-Identity 
header field, one or more dialogs supporting a session with inactive audio media exists for the user and the 
Contact header field provided by the SC UE at the establishment of the dialog supporting a session with 
inactive audio media which became inactive most recently includes the g.3gpp. mid-call media feature tag as 
described in annex C; 

3. the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; and 

4. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, and before determining that the SCC AS is not able to identify one dialog for session transfer, the SCC 
AS may: 

1 . if more than one dialog supporting a session exists for the user identified in the P-Asserted-Identity header field, 
and exactly one dialog supporting a session with active audio media exists, and a SIP 2xx response has been sent 
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for that dialog and there is at least one remaining dialog supporting a session with inactive audio media, release 
all dialogs supporting a session with inactive audio media except the one with the audio media which became 
inactive most recently and continue the session transfer procedures with the dialog supporting a session with 
active audio media; 

2. if more than one dialog supporting a session with active audio media exists for the user identified in the P- 
Asserted-Identity header field and a SIP 2xx response has been sent for these dialogs, release all dialogs 
supporting a session with audio media except two with the audio media which became active most recently and 
continue the session transfer procedures with the dialog supporting a session with the audio media which became 
active most recently; and 

3. if no dialog supporting a session with active audio media exists for the user identified in the P-Asserted-Identity 
header field, one or more dialogs supporting a session with inactive audio media exists for the user and a SIP 2xx 
response has been sent for these dialogs then the SCC AS may release all dialogs supporting a session with audio 
media except the one with the audio media which became inactive most recently and continue the session 
transfer procedures with the dialog supporting a session with inactive audio media. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall include the g.3gpp. mid-call media feature tag as described in annex C in the Contact 
header field of the SIP 2xx response to the SIP INVITE request due to static STN. 

When the SCC AS applies the MSC Server assisted mid-call feature and a dialog supporting a session with inactive 
audio media was associated with the SIP INVITE request due to static STN, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall set the directionality of the audio media in the SDP offer as used in the session with 
remote UE. 

If: 

- the SCC AS applies the MSC Server assisted mid-call feature; 

- the session associated with the SIP INVITE request due to static STN is related to a subscription as described in 
subclause 7.3.3; and 

a SIP 2xx response was received to the last SIP NOTIFY request with conference information sent to the UE 
within the related subscription; 

then the SCC AS shall send a SIP INFO request towards the MSC Server as specified in 3GPP TS 24.229 [2] and draft- 
ietf-sipcore-info-events [54] in the dialog created by the SIP INVITE request due to static STN. The SCC AS shall 
populate the SIP INFO request as follows: 

1. include the Info-Package header field as specified in draft-ietf-sipcore-info-events [54] with g.3gpp. mid-call 
package name; and 

2. include application/vnd.3gpp.mid-call+xml XML body contaning the participants extracted as specified in the 
subclause 9.1A of the subscription related to the session associated with the SIP INVITE request due to static 
STN as described in subclause 7.3.3. 

If the SCC AS applies the MSC Server assisted mid-call feature, two SIP dialogs supporting a session with an audio 
media exist for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent for those 
dialogs then the SCC AS shall send a SIP REFER request towards the MSC Server in accordance with the procedures 
specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and IETF RFC 4488 [20] in the dialog created by the SIP 
INVITE request due to static STN. The SCC AS shall populate the SIP REFER request as follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20]; 

3. the Refer-To header field containing the information related to the additional transferred session, i.e. session 
with an audio media other than the session associated with the SIP INVITE request due to static STN, i.e. set to 
the additional transferred session SCC AS URI and the following URI header fields: 

A. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session with the SC UE; 

B. the Require URI header field populated with the option tag value "tdialog"; 
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C. the To URI header field populated as specified in IETF RFC 3261 [19], containing the P-Asserted-Identity 
provided by the remote UE during the session establishment; 

D. the From URI header field populated as specified in IETF RFC 3261 [19], containing the public user identity 
of the SC UE provided during the session establishment; 

E. the Content-Type header field with "application/sdp"; and 

F. the "body" URI header field populated with an SDP body describing the media streams as negotiated in the 
session with the remote UE and: 

a. if directionality used by SC UE is "sendrecv" or "sendonly", with the "sendonly" directionality; and 

b. if directionality used by SC UE is "recvonly" or "inactive", with the "inactive" directionality. 

4. the Content-Type header field with the value set to MIME type as specified in the annex D.1.3; and 

5. a XML body compliant to the XML schema specified in the annex D.1.2. If 

A. the session associated with the SIP INVITE request due to static STN is not related to any subscription as 
described in subclause 7.3.3; 

B. the additional transferred session is related to a subscription as described in subclause 7.3.3; and 

C. a SIP 2xx response was received to the last SIP NOTIFY request with conference information sent to the UE 
within the related subscription; 

then SCC AS shall populate the XML body with the participants extracted as specified in the subclause 9.1 A of 
the subscription related to the additional transferred session as specified in subclause 7.3.3. 

The SCC AS shall consider dialog supporting a session with audio media: 

which has "sendonly" or "inactive" directionality at the SC UE as inactive; and 

which has "recvonly" or "sendrecv" directionality at the SC UE as active; 
in this subclause and in the referenced subclauses. 



9.3.3 SCC AS procedures for CS to PS access transfer 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg offering PS media only, the 
SCC AS shall follow the procedures specified in subclause 10.3.2. 

When the SCC AS receives a SIP INVITE request due to static STI, the SCC AS shall associate the SIP INVITE 
request with an ongoing dialog supporting a session. By an ongoing dialog supporting a session, it is meant a dialog for 
which a SIP 2xx response to the initial SIP INVITE request has been sent or received. Multiple dialogs supporting a 
session associated with the same SC UE may have been anchored when the SCC AS receives a SIP INVITE request due 
to static STI. This can occur in the event that the UE does not succeed in releasing all dialogs supporting a session with 
inactive audio media or if the UE supports the MSC Server assisted mid-call feature, in which case the identification of 
the associated dialog is subject to the following conditions: 

1 . if only one dialog supporting a session with active audio media exists for the user identified in the P-Asserted- 
Identity header field and a 2xx response has been sent, then continue the session transfer procedures; 

2. if no dialogs supporting a session with active audio media exist for the user identified in the P-Asserted-Identity 
header field and a SIP 2xx response has been sent and the SCC AS does not apply the MSC Server assisted mid- 
call feature as specified in subclause 9.3.4, then send a SIP 480 (Temporarily Unavailable) response to reject the 
SIP INVITE request relating to the session transfer; 

3. if more than one dialog supporting a session exists for the user identified in the P- Asserted -Identity header field 
and exactly one dialog supporting a session with active audio media and a SIP 2xx response has been sent for 
that dialog, then: 

A. if the remaining dialogs support a session with inactive audio media and the SCC AS does not apply the 
MSC Server assisted mid-call feature as specified in subclause 9.3.4, then the SCC AS may release the 
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dialogs supporting a session with inactive audio media and continue the session transfer procedures with the 
dialog supporting a session with active audio media; and 

4. if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

Continuing the session transfer procedures, the SCC AS sends a SIP re-INVITE request towards the remote UE using 
the existing established dialog. The SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to the static STI, 
by following the rules of 3GPP TS 24.229 [2] . 

Upon receiving the SIP ACK request originated from the UE, the SCC AS shall initiate release of the source access leg 
by sending a SIP BYE request over the source access leg. 

If, subsequent to initiating the SIP re-INVITE request to the remote UE, and prior to the SIP ACK request originated 
from the UE being received from the IM CN subsystem for the source access leg, the SCC AS decides (for any reason) 
to reject the session transfer request back to the UE (e.g. by sending a SIP 4xx response), the SCC AS shall release the 
target access leg and maintain the source access leg. 

9.3.4 SCC AS procedures for CS to PS access transfer with MSC server 
assisted mid-call feature 

The SCC AS shall apply the MSC Server assisted mid-call feature if: 

1. the Contact header field of the SIP INVITE request due to static STI includes the g.3gpp. mid-call media feature 
tag as specified in annex C; 

2. the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; and 

3. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.3, and before determining that the SCC AS is not able to identify one dialog for session transfer, SCC AS 
may: 

1 . if more than one dialog exists for the user identified in the P-Asserted-Identity header field, and exactly one 
dialog supporting a session with active audio media exists, and a SIP 2xx response has been sent for that dialog 
and there is at least one remaining dialog supporting a session with inactive audio media, release all dialogs 
supporting a session with inactive audio media except the one with the audio media which became inactive most 
recently and continue the session transfer procedures with the dialog supporting a session with active audio 
media ; and 

2. if no dialog supporting a session with active audio media exists for the user identified in the P-Asserted-Identity 
header field, one or more dialogs supporting a session with inactive audio media exists for the user and a SIP 2xx 
response has been sent for these dialogs then the SCC AS may release all dialogs supporting a session with audio 
media except the one with the audio media which became inactive most recently and continue the session 
transfer procedures with the dialog supporting a session with inactive audio media. 

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in 
subclause 9.3.2, the SCC AS shall include the g.3gpp. mid-call media feature tag as described in annex C in the Contact 
header field of the SIP 2xx response to the SIP INVITE request due to static STI. 

When the SCC AS applies the MSC Server assisted mid-call feature and a dialog supporting a session with inactive 
audio media was associated with the SIP INVITE request due to static STI, in addition to the procedures described in 
subclause 9.3.3, the SCC AS shall set the directionality of the audio media in the SDP offer as used in the session with 
remote UE. 

If the SCC AS applies the MSC Server assisted mid-call feature, two SIP dialogs supporting a session with an audio 
media exist for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent for those 
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dialogs then the SCC AS shall send a SIP REFER request towards the SC UE in accordance with the procedures 
specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] and IETF RFC 4488 [20] in the dialog created by the SIP 
INVITE request due to static STL The SCC AS shall populate the SIP REFER request as follows: 

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20]; 

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20]; 

3. the Refer-To header field containing the information related to the session with an audio media other than the 
session associated with the SIP INVITE request due to static STI, i.e. set to the additional transferred session 
SCC AS URI and the following URI header fields: 

A. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session with the MSC Server; 

B. the Require URI header field populated with the option tag value "tdialog"; 

C. if the remote UE did not request privacy then the To URI header field populated as specified in 

IETF RFC 3261 [19], containing the P-Asserted-Identity provided by the remote UE during the session 
establishment; 

D. the From URI header field populated as specified in IETF RFC 3261 [19], containing the public user identity 
of the SC UE provided during the session establishment; 

E. the Content-Type URI header field with "application/sdp"; and 

F. the "body" URI header field populated with an SDP body describing the media streams as negotiated in the 
session with the remote UE and with directionality as used by the MSC Server; 

4. the Content-Type header field with the value set to MIME type specified in the annex D.1.3; and 

5. a XML body compliant to the XML schema specified in the annex D. 1.2. 
The SCC AS shall consider dialog supporting a session with audio media: 

- which has "sendonly" or "inactive" directionality at the MSC Server as inactive; and 

- which has "recvonly" or "sendrecv" directionality at the MSC Server as active; 
in this subclause and in the referenced subclauses. 

9.4 MSC Server enhanced for ICS 

9.4.1 MSC Server enhanced for ICS procedures for PS to CS session 
continuity with MSC server assisted mid-call feature 

If the MSC Server enhanced for ICS has registered for the user, it shall apply the procedures as specified in 
3GPPTS 29.292 [18]. 

If the MSC Server enhanced for ICS supports the MSC Server assisted mid-call feature, it shall populate the SIP 
INVITE request as follows: 

1. the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; 

2. the Accept header field containing the MIME type as specified in annex D.1.3; 

3. include in the Contact header field the g.3gpp. mid-call media feature tag as described in annex C; and 

4. the Recv-Info header field containing the g.3gpp. mid-call package name. 

NOTE 1: Since the MSC Server is not able to distinguish the dual radio access transfer from the regular session set 
up, the information elements above are added to every SIP INVITE request sent by the MSC Server. 
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Upon receiving a SIP INFO request with the Info-Package header field containing the g.3gpp. mid-call package name, if 
the MSC Server supports the MSC Server assisted mid-call feature and the SIP INVITE request established a session 
with conference focus, then the MSC Server enhanced for ICS shall associate the participants extracted from the 
application/vnd.3gpp.mid-call+xml MIME body with transaction identifiers calculated as in the table 9.2.1A-2 and with 
TI flag of the session. The offsets 0, 2, 3, 4, 5 are assigned to the participants in their order in the list of the extracted 
participants. 

Upon receiving a SIP REFER request 

1. with the Refer-Sub header field containing "false" value; 

2. with the Supported header field containing "norefersub" value; 

3. with the Refer-To header field containing a SIP URI with the Target-Dialog URI header field; 

4. sent inside an existing SIP dialog: 

A. which was originated by the MSC Server; and 

B. where the g.3gpp. mid-call media feature tag as specified in annex C was included in the Contact header field 
of the SIP 2xx response to the SIP INVITE request; and 

5. containing a MIME body of MIME type specified in the annex D. 1 .3; 

and if the MSC Server enhanced for ICS supports the MSC Server assisted mid-call feature, then the MSC Server 
enhanced for ICS shall: 

1. handle the SIP REFER request as specified in 3GPP TS 29.292 [18], IETF RFC 3515 [13] and 
IETF RFC 4488 [20]; and 

2. send a SIP INVITE request for transfer of an additional inactive session not using ICS capabilities in accordance 
with the procedures specified in 3GPP TS 29.292 [18] and IETF RFC 3515 [13]. Additionally, the MSC Server 
enhanced for ICS shall populate the SIP INVITE request as follows: 

A. header fields which were included as URI header fields in the URI in the Refer-To header field of the 
received SIP REFER request as specified in IETF RFC 3261 [19] except the "body" URI header field; 

B. include in the Contact header field the g.3gpp.mid-call media feature tag as described in annex C; and 

C. the SDP offer with: 

a. the same amount of the media descriptions as in the "body" URI header field in the URI in the Refer-To 
header field of the received SIP REFER request; 

b. each "m=" line having the same media type as the corresponding "m=" line in the "body" URI header 
field in the URI in the Refer-To header field of the received SIP REFER request; 

c. port set to zero value in each "m=" line whose corresponding "m=" line in the "body" URI header field in 
the URI in the Refer-To header field of the received SIP REFER request has port with zero value; and 

d. media directionality as in the "body" URI header field in the URI in the Refer-To header field of the 
received SIP REFER request 

NOTE 2: port can be sent to zero or non zero value for the offered "m=" line whose corresponding "m=" line in the 
"body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has 
port with nonzero value. 

If two sessions are transferred, the MSC Server enhanced for ICS shall: 

1. associate the SIP INVITE request for an additional inactive session with CS call with transaction identifier 
calculated as in the table 9.2.1A-1 and TI flag value as in mobile originated call; and; 

2. if the SIP INVITE request for an additional inactive session established a session with conference focus then 
associate the participants extracted from the application/vnd.3gpp.mid-call+xml MIME body included in the SIP 
REFER request with transaction identifiers calculated as in the table 9.2.1A-2 and with TI flag of the session. 
The offsets 0, 1, 2, 3, 4 are assigned to the participants in their order in the list of the extracted participants. 
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9.4.1 A MSC Server enhanced for ICS procedures for PS to CS session 

continuity with MSC server assisted mid-call feature for speech and 
video session 

If the MSC Server enhanced for ICS supports the MSC Server assisted mid-call feature, upon receiving the session state 
information which indicates an inactive speech and video session, the MSC Server enhanced for ICS shall send a SIP 
INVITE request for the additional inactive speech and video session as described in subclause 9.4.1. 

NOTE 1: If due to some reason (i.e. the current RAN type not supporting video, lack of resource, etc.) the video 

media can not be supported in CS network for the speech and video session, then the MSC Server can set 
the port to zero in the "m=" line for the video media in the SDP offer of the SIP INVITE request for the 
additional inactive session, so as to inform the SCC AS that the video media is deleted and only the audio 
media of the speech and video session is transferred to CS. 

NOTE 2: After successful transfer of a speech and video session and a speech session from PS to CS, if messages 
are received from the UE to switch between the two sessions (i.e. HOLD/Release message to hold/release 
the active session and Retrieve message to retrieve the inactive session), the MSC Server enhanced for 
ICS can perform the procedures as specified in 3GPP TS 29.292 [18], with the addition that the MSC 
Server enhanced for ICS can complete the in-call modification or Redial procedures as specified in 
3GPP TS 24.008 [8] to change the shared CS bearer of the two sessions from speech to multimedia, or 
vice versa, before sending a SIP UPDATE or SIP re-INVITE message to the SCC AS to resume the 
inactive session. 



1 Roles for PS-PS access transfer 
10.1 Introduction 

This clause specifies the procedures for PS-PS access transfer for both full media transfer case and partial media 
transfer case. Procedures are specified for the SC UE and the SCC AS. 



10.2 SCUE 



10.2.0 General 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been 
sent or received. 

The SC UE shall follow the procedures specified in subclause 6.1 to perform registration in the IM CN subsystem on 
the newly selected access network before performing PS-PS access transfer. 



1 0.2.1 Full session transfer 

To initiate PS-PS access transfer for a session, the SC UE shall send a SIP INVITE request over the Target Access Leg 
in accordance with UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request 
as follows: 

1 . the Request-URI set to the URI contained in the Contact header field returned at the creation of the dialog over 
the Source Access Leg; 

2. include in the Contact header field: 

A. a public GRUU or temporary GRUU as specified in 3 GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

B. the g.3gpp.ics media feature tag set to "principal" as specified in annex B of 3GPP TS 24.292 [4]; 
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3. select one of the following options: 

A. if usage of SIP Replaces extension is selected: 

a. the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier 
of the session to be transferred; and 

b. the Require header field populated with the option tag value "replaces"; 

B. if usage of SIP Target-Dialog extension is selected: 

a. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session to be transferred; and 

b. the Require header field populated with the option tag value "tdialog"; and 

4. the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SC UE shall create an SDP offer that contains the same 
number of media lines in the same order, where each media line corresponds to one of the media components in 
the original session, unless media components need to be added, and such that each media line indicates the 
same media type as its corresponding media component in the original session and contains at least one codec 
that was negotiated during the original session. 

A. - If the SC UE determines to remove a media component during the transfer, then the SC UE shall set the 

media line for this media component to a port number with value zero; and 

B. - If the SC UE determines to add new media component(s) during the transfer, then the SC UE shall include 

one additional media line with the desired media type and codecs for each new media component at the end 
of the SDP. 

NOTE: If an SC UE is an ICS UE with an ongoing session using CS bearer and Gm reference point for service 
control signalling, the SC UE can perform an access transfer of the service control signalling from the 
current IP-CAN to a new IP-CAN with the same capabilities (i.e. supporting CS and PS bearers, 
simultaneously) while retaining the media component in the CS access network by including the 
description of audio/video media over a circuit switched bearer in the SDP of the access transfer request, 
so that service continuity of the session is maintained. 

Upon receiving SIP 2xx response for the SIP INVITE request sent over the Target Access Leg and sending SIP ACK 
request, if the dialog over the Source Access Leg is still active, the SC UE shall send a SIP BYE request to the SCC AS 
over the Source Access Leg to terminate the original session. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request sent over the Target Access Leg, then PS- 
PS access transfer has not completed successfully and the call will continue in the Source Access Leg. 

1 0.2. 1 A Additional procedures for full session transfer when MSC server 
assisted mid-call feature is supported 

In addition to the procedures described in subclause 10.2.1, if the SC UE supports the MSC Server assisted mid-call 
feature, the SC UE shall include in the Contact header field of the SIP INVITE request the g.3gpp. mid-call media 
feature tag as described in annex C. 

1 0.2.2 Partial session transfer 

To initiate PS-PS access transfer for a session, the SC UE shall send a SIP INVITE request over the Target Access Leg 
in accordance with UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request 
as follows: 

1 . the Request-URI set to the URI contained in the Contact header field returned at the creation of the dialog over 
the Source Access Leg; 

2. include in the Contact header field: 

A. a public GRUU or temporary GRUU as specified in 3 GPP TS 24.229 [2] if a GRUU was received at 
registration; and 
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B. the g.3gpp.ics media feature tag set to "principal" as specified in annex B of 3GPP TS 24.292 [4]; 

3. the Require header field with the option tag 'tdialog' included; 

4. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of 
the session to be transferred; and 

5. the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SC UE shall create an SDP offer that contains the same 
number of media lines in the same order, where each media line corresponds to one of the media components in 
the original session, unless media components need to be added during the session transfer, and such that each 
media line indicates the same media type as its corresponding media component in the original session and 
contains at least one codec that was negotiated during the original session. 

A. If the SC UE determines to keep the media component on the Source Access Leg, then the SCUE shall set 
the media line for this media component to a port number with value zero; and 

B. If the SC UE determines to add new media component(s) during the transfer, then the SC UE shall include 
one additional media line with the desired media type and codecs for each new media component at the end 
of the SDP. 

NOTE: If an SC UE is an ICS UE with an ongoing session using CS bearer and Gm reference point for service 
control signalling, the SC UE can perform an access transfer of the service control signalling from the 
current IP-CAN to a new IP-CAN with the same capabilities (i.e. supporting CS and PS bearers, 
simultaneously) while retaining the media component in the CS access network by including the 
description of audio/video media over a circuit switched bearer in the SDP of the access transfer request, 
so that service continuity of the session is maintained. 

Upon receiving SIP 2xx response for the SIP INVITE request sent over the Target Access Leg and sending SIP ACK 
request, the SC UE shall send a SIP re-INVITE request to the SCC AS over the Source Access Leg to update the 
original session. The SC UE shall populate the SIP re-INVITE request as follows: 

1 . the SDP payload set for all the media component(s) within the original session, in accordance with the UE SDP 
origination procedures specified in 3GPP TS 24.229 [2]. The SC UE shall set the port number for a media 
component to zero if that media component has been transferred to the Target Access Leg or has to be removed. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request sent over the Target Access Leg, then PS- 
PS access transfer has not completed successfully and the call will continue in the Source Access Leg. 

1 0.2.3 Additional procedures for partial session transfer when MSC server 
assisted mid-call feature is supported 

In addition to the procedures described in subclause 10.2.2, if the SC UE supports the MSC Server assisted mid-call 
feature, the SC UE shall include in the Contact header field of the SIP INVITE request the g.3gpp. mid-call media 
feature tag as described in annex C. 

10.3 SCC AS 

1 0.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field and not containing Inter UE Transfer SCC AS URI in the Request- 
URL In the procedures below such requests are known as "SIP INVITE requests due to STI". 

NOTE 1: If the Request-URI contains the additional transferred session SCC AS URI, the PS-PS access transfer 

procedure is used to transfer the additional transferred session during PS-CS access transfer with the MSC 
server assisted mid-call feature. 
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NOTE 2: The media streams that need to be transferred are identified using information described in the subsequent 
sections. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 0.3.2 PS to PS access transfer procedures at the SCC AS 

This subclause applies to reception of a SIP INVITE request due to STI with a PS media only. 

When the SCC AS receives a SIP INVITE request on the Target Access Leg due to STI, the SCC AS shall: 

associate the SIP INVITE received on the Target Access Leg with an ongoing SIP dialog i.e. identify the 
Source Access Leg. The Source Access Leg is identified by matching the dialog ID present in the Replaces (see 
IETF RFC 3891 [10]) or Target Dialog header field (see IETF RFC 4538 [1 1]) of the SIP INVITE with an 
ongoing dialog. By an ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP 
INVITE request has been sent or received; 

if the SCC AS is unable to associate the SIP INVITE with a unique ongoing dialog, send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not 
processes the remaining steps; 

if the SIP INVITE request contains a Replaces header field: 

a) follow the procedures defined in IETF RFC 3891 [10] for replacing the Source Access Leg with the SIP 
request received on the Target Access Leg, including terminating the Source Access Leg by sending a SIP 
BYE towards the SC UE in accordance with 3GPP TS 24.229 [8]; and 

b) send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS 
shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to STI 
received on the Target Access Leg, by following the rules of 3GPP TS 24.229 [2]. 

otherwise, if the SIP INVITE request contains a Target Dialog header field: 

a) if the number of media lines in the Target Access Leg is less than the number of media lines in the Source 
Access Leg or the media type for the corresponding media lines is not the same as in the original session, 
send a SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the 
remaining steps; 

b) otherwise, send a SIP re-INVITE request towards the remote UE using the existing established dialog. The 
SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) include a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], containing the following 
media information: 

the media characteristics as received in the SIP INVITE request due to STI received on the Target 
Access Leg for media streams whose port is not set to zero; and 

- for the media streams in the SIP INVITE request due to STI whose port is set to zero, include the 
corresponding media characteristics of those streams from the Source Access Leg, 

c) for a full media transfer, send a SIP BYE towards the SC UE in accordance with 3GPP TS 24.229 [2]; 
otherwise, for a partial media transfer, after receiving the SIP ACK request from the SC UE on the Target 
Access Leg, upon receiving an update (e.g. SIP re-INVITE) from the SC UE on the Source Access Leg, 
process the update request in accordance with 3GPP TS 24.229 [2]. 
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If, subsequent to initiating the SIP re-INVITE request to the remote UE, and prior to the SIP ACK request being 
received on the Target Access Leg, the SCC AS decides (for any reason) to reject the access transfer request (e.g. by 
sending a 4xx response), the SCC AS shall release the Target Access Leg, retain the Source Access Leg, and update the 
remote leg to match the Source Access Leg. 

1 0.3.3 Additional SCC AS procedures for PS to PS access transfer when 
MSC server assisted mid-call feature is supported 

If: 

1 . the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; 

2. the g.3gpp. mid-call media feature tag as described in annex C is included in the Contact header field of the SIP 
INVITE request due to STI; and 

3. the SCC AS is aware that all MSC Servers in the network where the UE is registered which can be involved in 
the SRVCC procedures support the MSC Server assisted mid-call feature; 

then the SCC AS shall include the g.3gpp. mid-call media feature tag as described in annex C in the Contact header field 
of the SIP 2xx response to the SIP INVITE request due to STI in addition to the procedures described in 
subclause 10.3.2. 



1 1 Roles for PS-PS access transfer in conjunction with 
PS-CS access transfer 

11.1 Introduction 

This clause specifies the procedures for PS-PS access transfer in conjunction with PS-CS access transfer. Procedures are 
specified for the SC UE and the SCC AS. For SC UE or SCC AS not supporting ICS procedures, PS-PS access transfer 
with a remote end in conjunction with PS-CS access transfer with the same remote end is only possible when the UE is 
active in a single CS session with full-duplex speech with the remote end i.e. support of session transfer with more than 
one session containing full-duplex speech component is not provided. 

11.2 SCUE 

1 1 .2.1 SC UE procedures for PS to PS+CS access transfer 

11.2.1.1 General 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been 
sent or received. 

1 1 .2.1 .2 SC UE procedures for PS to PS+CS access transfer using ICS 

This subclause applies for IMS sessions containing not only speech media component, otherwise subclause 9.2.1 
applies. 

If SC using ICS is enabled then if the SC UE is using Gm, then for each session to be transferred and starting with the 
session with active full-duplex speech component, the SC UE shall send a SIP INVITE request to the SCC AS as 
specified for call origination for ICS UE using Gm in 3GPP TS 24.292 [4]. The SC UE shall populate the SIP INVITE 
request as specified for PS-PS access transfer with full media transfer in subclause 10.2.1 with the following exceptions: 

- The SC UE shall indicate in the SIP INVITE request that the speech media is using CS bearer with its 
corresponding media description. 
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When sending the SIP INVITE request for the sessions with inactive full-duplex speech component and if 
precondition is used, the SC UE shall indicate that the related local preconditions for the speech component are 
met. 

- For the session with active full-duplex speech component, upon receiving the PSI DN from the SCC AS, the SC 
UE shall follow the procedures for call origination for ICS UE using Gm in 3GPP TS 24.292 [4] to set up the CS 
bearer. 

If service control over Gm for the CS bearer is retained on the source access leg, the SC UE shall: 

send an SIP INVITE request as specified for partial session transfer in subclause 10.2.2. indicating transfer of 
non-speech media to the target access leg; and 

- send a SIP re-INVITE request over the source access leg indicating that the speech media is to be transferred to a 
CS bearer as described in 3GPP TS 24.292 [4] subclause 8.2.2.2. If other media components are retained or 
added on the source access leg, then these are included in the SDP offer. 

For the session with active full-duplex speech component, upon receiving the SCC AS PSI DN from the SCC AS, the 
SC UE shall follow the procedures for call origination for ICS UE using Gm in 3GPP TS 24.292 [4] to set up the CS 
bearer. 

1 1 .2.1 .3 SC UE procedures for PS to PS+CS access transfer not using ICS 

If the SC UE is not using ICS capabilities and if the SC UE does not apply the MSC server assisted mid-call feature as 
specified in subclause 9.2.1 A, then access transfer is only possible when the UE is active in a single session with full- 
duplex speech media component. 

For the non-speech components to be transferred to the PS Target Access Leg, the SC UE shall send a SIP INVITE 
request to the SCC AS as specified for PS-PS access transfer with partial media transfer in subclause 10.2.1. For the 
speech component to be transferred to the CS Target Access leg, the SC UE shall send to the SCC AS a CC SETUP 
message as specified in 3GPP TS 24.008 [8]. When sending the CC SETUP message, the SC UE shall populate the CC 
SETUP message as follows: 

1) the called party BCD number information element set to the STN; 

2) Type Of Number set to "International" and Numbering Plan Indicator set to "E. 164". in the Called Party BCD 
Number information element. 

Upon receiving the SIP 2xx response from the SCC AS for the PS Target Access Leg and sending SIP ACK request and 
upon receiving CS call setup confirmation message, e.g. CC CONNECT message, for the CS Target Access Leg, the 
SC UE shall send a SIP BYE request to terminate the Source Access Leg, following the procedures specified in 
3GPPTS 24.229 [2]. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access leg and receives 
CS call setup failure message for the CS Target Access Leg, then session transfer has not occurred and the call will 
continue in the original domains. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access Leg and 
receives CS call setup confirmation message for the CS Target Access Leg, then the session transfer is only successful 
for part of the media components. The SC UE shall update the Source Access leg by following the procedures specified 
for PS-PS access transfer with partial media transfer in subclause 10.2.2 to indicate that all media components other 
than the speech component are still maintained on the Source Access Leg. 

If the SC UE receives CS call setup failure message for the CS Target Access Leg but receives a SIP 2xx response for 
the PS Target Access Leg, then the session transfer is only successful for part of the media components. Upon sending 
SIP ACK request, the SC UE shall update the Source Access leg by following the procedures specified for PS-PS 
access transfer with partial media transfer in subclause 10.2.2 to indicate that the speech component is still maintained 
on the Source Access Leg. 

1 1 .2.1 .4 SC UE procedures for PS to PS+CS access transfer not using ICS with MSC 
server assisted mid-call feature 

In addition to the procedures described in subclause 1 1.2.1.3 the SC UE shall: 
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- act as described in subclause 9.2.1 A; and 

if the MSC server assisted mid-call feature is applied, transfer the non-speech components of the additional 
transferred session to the PS Target Access Leg as specified for PS-PS access transfer with partial media transfer 
in subclause 10.2.2. 

1 1 .2.2 SC UE procedures for PS+CS to PS access transfer 

11.2.2.1 General 

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, 
it is meant a CS call for which the CC CONNECT message has been sent or received or a call for which the SIP 2xx 
response for the initial SIP INVITE request to establish this session has been sent or received. 

If not already registered over the PS Target Access Leg, the SC UE shall follow the procedures specified in 
subclause 6.2 to perform IM CN subsystem registration over the Target Access Leg before performing PS/CS to PS 
access transfer. 

1 1 .2.2.2 SC UE procedures for PS+CS to PS access transfer using ICS 

If SC using ICS is enabled then if the original sessions are established using ICS capabilities as defined in 
3GPP TS 24.292 [4], then for each session to be transferred and starting with the session with active full-duplex speech 
media component, the SC UE shall send a SIP INVITE request to the SCC AS in accordance with the UE procedures 
specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as specified for PS-PS access 
transfer with full media transfer in subclause 10.2.1. The SC UE shall indicate in the SIP INVITE request that the 
speech media component is using PS media. 

Upon receiving SIP BYE request for the Source Access Leg, the SC UE shall follow the ICS using Gm procedures 
specified in 3GPP TS 24.292 [4] to release the session. The SC UE also releases the associated CS bearer if no other 
sessions depend on the CS bearer. 

1 1 .2.2.3 SC UE procedures for PS+CS to PS access transfer not using ICS 

If the original sessions are not established using ICS capabilities, then access transfer is only possible when the SC UE 
has a single session with active full-duplex speech media component. The SC UE shall send a SIP INVITE request to 
the SCC AS in accordance with the UE procedures specified in 3GPP TS 24.229 [2]. 

The SC UE shall populate the SIP INVITE request as follows: 

- the Request-URI set to static STI; 

- the Require header field including "replaces" option tag; 

- the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier of the 
session to be transferred on the PS Source Access Leg; and 

the SDP payload set for the media component(s) to be transferred, in accordance the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SC UE shall create an SDP offer that contains media 
components in the following order: 

1) the same number of media lines, each corresponding to one of the media components in the session on the PS 
Source Access Leg; For each media line the SC UE shall indicate the same media type as its corresponding 
media component in the original session and indicate at least one codec that was negotiated during the 
original session. If the SC UE determines to remove a media component during the transfer, then the SC UE 
shall set the media line for this media component to include a port number with value zero; 

2) one speech media component to be transferred, corresponding to the speech media component in the session 
on the CS Source Access Leg; and 

3) if the SC UE determines to add new media component(s) during the transfer, then one additional media line 
with the desired media type and codecs each new media component. 
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If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the original domains. 

1 1 .3 SCC AS 

1 1 .3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field and not containing Inter UE Transfer SCC AS URI in the Request- 
URL In the procedures below, such requests are known as "SIP INVITE requests due to STI". 

SIP INVITE requests routed to the SCC AS containing either a static STN or an IMRN in the Request-URL In 
the procedures below, such requests are known as "SIP INVITE requests due to static STN". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URI and a STI in the 
Replaces or Target-Dialog header field. In the procedures below, such requests are known as "SIP INVITE 
requests due to two STIs". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
subclauses 11.3.2 and 11.3.3. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 1 .3.2 SCC AS procedures for PS to PS+CS access transfer 

This subclause does not apply to recepetion of a SIP INVITE request due to STI with a CS media. 

When the SCC AS receives a SIP INVITE request due to STI with PS and CS media on the Target Access Leg, the 
SCC AS shall follow the PS-PS Access Transfer procedures specified in subclause 10.3.2. with the following 
exceptions: 

If the SIP INVITE request includes an active speech media component using CS bearer, then the SCC AS shall follow 
the procedures for SCC AS for service control over Gm in 3GPP TS 24.292 [4] to send the PSI DN to the SC UE and 
wait for the SC UE to set up CS bearer before sending re-INVITE to the remote UE. 

- The SCC AS shall correlate the STI with the allocated PSI DN in order to identify the remote leg to be updated. 

- If service control over Gm is retained on the source access leg, and the SCC AS receives a re-INVITE request 
indicating CS bearer on an existing session, the SCC AS shall follow procedures as described in 

3GPP TS 24.292 [4] subclause 8.4.2 to send the PSI DN to the SC UE and wait for the SC UE to set up CS 
bearer before sending re-INVITE to the remote end. 

- The SCC AS shall include a new SDP offer in the re-INVITE request, following the rules specified in 
3GPP TS 24.229 [2], containing the following media information: 

the media characteristics as received in the SIP INVITE request due to STI with PS+CS media received on 
the Target Access Leg for media streams whose port is not set to zero; and 

- the media characteristics as received in the SIP re-INVITE request for media streams whose port is not set to 
zero. 

When the SCC AS receives a SIP INVITE request due to static STN on the Target Access Leg, the SCC AS shall 
follow the PS-CS Access Transfer procedures specified in subclause 9.3.2. However, as the Source Access Leg contains 
media components other than speech component, the SCC AS does not initiate release for Source Access Leg. 

1 1 .3.3 SCC AS procedures for PS+CS to PS access transfer 

This subclause applies to reception of a SIP INVITE request due to STI with a PS media only. 
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When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
PS-PS access transfer procedures specified in subclause 10.3.2. 

When the SCC AS receives a SIP INVITE request due to two STIs on the Target Access Leg, the SCC AS shall: 
associate the SIP INVITE request received on the Target Access Leg with two ongoing sessions: 

a) an ongoing SIP dialog on the PS Source Access Leg: This is done by matching the dialog ID present in the 
Replaces header field (see IETF RFC 3891 [10]) or Target-Dialog header field (see IETF RFC 4538 [11]) of 
the SIP INVITE request with an ongoing dialog. By an ongoing SIP dialog, it is meant a dialog for which a 
SIP 2xx response to the initial SIP INVITE request has been sent or received; 

b) a different ongoing SIP dialog with active full-duplex speech component: 

if the SCC AS is unable to associate the SIP INVITE request with either one of the above two dialogs, send a 
SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and 
not process the remaining steps; and 

if the session transfer is possible: 

a) follow the procedures defined in IETF RFC 3891 [10] for replacing the two sessions on the Source Access 
Legs with the SIP request received on the Target Access Leg, including terminating the two Source Access 
Legs by sending a SIP BYE request on each session towards the SC UE in accordance with 

3GPPTS 24.229 [2]; and 

b) send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS 
shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to two 
STIs received on the Target Access Leg, by following the rules of 3GPP TS 24.229 [2]. 



1 2 Roles for PS-CS access transfer, Single Radio 

12.1 Introduction 

This clause specifies the procedures for PS-CS access transfer in Single Radio VCC. Procedures are specified for the 
SC UE and the SCC AS. For SC UE or SCC AS not supporting ICS procedures, PS-CS access transfer in SR-VCC is 
only possible when SC is enabled, the UE is active in a single session with full-duplex speech i.e. support of session 
transfer with more than one session containing full-duplex speech component is not provided. 

12.2 SC UE procedures for PS to CS access transfer, SR-VCC 

12.2.1 General 

The SC UE may be engaged in one or more ongoing sessions before SR-VCC access transfer is performed. By an 
ongoing session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this 
session has been sent or received. 

12.2.2 ICS-based 

If: 

- SC using ICS is enabled; 

- the Gm reference point is retained upon PS handover procedure; 
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- the SC UE is using ICS capabilities as defined in 3GPP TS 24.292 [4]; and 

- SR-VCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 
the SC UE, in order to add Gm control for the newly established CS session, shall: 

- send a SIP re-INVITE request for each speech session to be transferred, starting with the session with active full- 
duplex speech component that was most recently made active; and 

within the SDP offer indicate the media line for all active and held audio streams as an audio stream over circuit 
switched bearer in accordance with 3GPP TS 24.292 [4]. If the precondition mechanism is used, the SC UE shall 
indicate the related local preconditions as met. 

NOTE: Within SR-VCC the handover is performed on PS level. Due to this, the SIP dialog established over the 
source PS access network stays the same after SR-VCC procedures, e.g. the IP address of the UE, the 
Call-ID, the P-CSCF do not change. Therefore in this case a re-INVITE needs to be sent to add ICS- 
control for the CS bearer. 

12.2.3 Not based on ICS 

After successful SR-VCC procedures (as described in 3GPP TS 24.008 [8]), if the SC UE is not using ICS capabilities 
and the SC UE does not apply the MSC Server assisted mid-call feature as specified in subclause 12.2.3A, the SC UE 
shall replace the most recently active PS audio session with the newly established CS voice call. 

NOTE: In the case when ICS is not supported or used and the SC UE does not apply the MSC Server assisted 
mid-call feature, only the most recently active audio call is transferred from PS to CS audio. 

If: 

the Gm reference point is retained upon PS handover; 

- the SC UE is not using ICS capabilities; and 

- SR-VCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 
the SC UE shall: 

- send a SIP re-INVITE request to the SCC AS as specified for media removal in subclause 13.2.1; and 

- indicate in the SDP offer the full-duplex speech media as removed. 

12.2.3A Not based on ICS with MSC Server assisted mid-call feature 

After successful SR-VCC procedures (as described in 3GPP TS 24.008 [8]), if: 

1. the SC UE is not using ICS capabilities; 

2. the SC UE supports the MSC Server assisted mid-call feature; and 

3. one of the following is true: 

A. there is at least one active PS audio session and the Contact header field received by the SC UE at the 
establishment of the active PS audio session, which has been most recently made active, includes the 
g.3gpp. mid-call media feature tag as described in annex C; or 

B. there is no active PS audio session and the Contact header field received by the SC UE at the establishment 
of the inactive PS audio session which became inactive most recently includes the g.3gpp. mid-call media 
feature tag as described in annex C. 

then the SC UE shall apply the MSC Server assisted mid-call feature as follows: 

1 . if two or more active PS audio sessions exist, the SC UE shall replace the PS audio components of the two most 
recently active PS audio sessions with the newly established active and held CS voice calls; 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 



45 



ETSI TS 124 237 V9.4.0 (2010-10) 



2. if one active PS audio session exists and one or more inactive PS audio sessions exist, the SC UE shall replace 
the PS audio components of the active PS audio session and of the most recently inactive PS audio session with 
the newly established active and held CS voice calls; 

3. if one active PS audio session exists and no inactive PS audio sessions exist, the SC UE shall replace the PS 
audio component of the active PS audio session with the newly established active CS voice call; and 

4. if no active PS audio session exists and one or more inactive PS audio session exists, the SC UE shall replace the 
PS audio component of the inactive PS audio session which became inactive most recently with the newly 
established held CS voice call. 

For each session, the SC UE shall proceed as specified in subclause 12.2.3. 

If two sessions are transferred, the SC UE shall associate the additional transferred session with CS call with transaction 
identifier 1 and TI flag value as in mobile terminated call. 

NOTE: The active session transaction identifier value is described in 3GPP TS 24.008 [8] 

If a transferred session is with conference focus then the SC UE shall associate the transaction identifiers to participants 
as in subclause 9.2.1 A. 

The SC UE shall consider session with audio media: 

which has "sendonly" or "inactive" directionality as inactive; and 

which has "recvonly" or "sendrecv" directionality as active; 
in this subclause and in the referenced subclauses. 

If single inactive session is transferred, the SC UE shall associate the transferred session with CS call with transaction 
identifier and TI flag value as in mobile terminated call. 

12.2.4 Abnormal cases 

If the SC UE engaged in one or more ongoing IMS sessions receives a SM NOTIFICATION message containing an 

"SRVCC handover cancelled, IMS session re-establishment required" as described in 3GPP TS 24.008 [8] or 

3GPP TS 24.301 [52] depending on the access in use, then the SC UE shall send a SIP re-INVITE request containing: 

1) an SDP offer, including the media characteristics as used in the existing dialog; and 

2) a Reason header field containing protocol "SIP" and reason parameter "cause" with value "487" as specified in 
IETF RFC 3326 [57]; 

by following the rules of 3GPP TS 24.229 [2] in each transferred session. 

12.3 SCC AS 

1 2.3.1 SCC AS procedures for PS to CS access transfer, SR-VCC 

The SCC AS needs to distinguish between the following SIP INVITE requests to provide specific functionality for SR- 
VCC: 

- SIP INVITE request routed to the SCC AS due to a STN-SR belonging to the subscribed user in the Request- 
URL These SIP INVITE requests originate from the MSC server. In the procedures below, such requests are 
known as "SIP INVITE requests due to STN-SR". 

- SIP re-INVITE request routed to the SCC AS containing one or more already existing media lines for audio 
indicate a CS bearer. In the procedures below, such requests are known as "SIP re-INVITE requests adding ICS 
control". 

- SIP re-INVITE request routed to the SCC AS containing one or more already existing media lines for audio 
indicate the port set to "0". In the procedures below, such requests are known as "SIP re-INVITE requests for 
non-ICS control". 
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When the SCC AS receives a SIP INVITE request due to STN-SR on the Target Access Leg, and the SCC AS does not 
apply MSC Server assisted mid-call feature as described in subclause 12.3.2, the SCC AS shall follow the PS-CS access 
transfer procedures specified in subclause 9.3.2 for the session with active full-duplex speech component that was most 
recently made active. However, the SCC AS does not initiate release for Source Access Leg unless after some specific 
time defined by the operator policy. 

If the SCC AS has sent a SIP 480 (Temporarily Unavailable) response to reject a SIP INVITE request due to STN-SR 
on the Target Access Leg: 

1) if the speech media flow to be transferred was the only media flow in the SIP dialog, the SCC AS shall release 
the remote leg as specified in 3GPP TS 24.229 [2]; or 

2) if the SIP dialog contains other media flows than the active speech flow, the SCC AS shall modify the remote leg 
and remove the speech media flow, as specified in 3GPP TS 24.229 [2]. 

When the SCC AS receives a SIP re-INVITE request for adding ICS control, the SCC AS shall follow the procedures as 
described for ICS using Gm in subclause 13.3.2. 

NOTE: When using the ICS controlled CS bearer, only one audio call can be active at a time. Nevertheless, 

several calls can be held in parallel. If the user decides to switch to another (previously held) call, the ICS 
controlled CS bearer is re-used for this call. Therefore no specific procedures for handling of held calls in 
the case of ICS controlled CS bearer are needed. 

When the SCC AS receives a SIP re-INVITE for non-ICS control, the SCC AS shall follow the media removal 
procedures as specified in subclause 13.3.1. 

Unless the MSC Server assisted mid-call feature applies, as only the most recent active audio call is transferred from PS 
to CS audio, the SCC AS shall drop all other previously existing audio session from this UE and indicate them 
accordingly in the SDP Offer sent within SIP re-INVITE requests towards the remote UE. 

1 2.3.2 SCC AS procedures for PS to CS access transfer with MSC server 
assisted mid-call feature, SR-VCC 

if 

1. the SC UE included the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact 
header field during establishment of the session associated with the SIP INVITE request due to static STN, the 
SCC AS local policy requires delaying application of the MSC Server assisted mid-call feature for a time given 
by local policy and the inactive session transfer request has not been received within a time given by local policy 
after the reception of the SIP INVITE request due to static STN; 

2. the SC UE included the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact 
header field during establishment of the session associated with the SIP INVITE request due to static STN and 
the SCC AS local policy does not require delaying application of the MSC Server assisted mid-call feature for a 
time given by local policy; or 

3. the SC UE did not include the g.3gpp.ics media feature tag as specified in the 3GPP TS 24.292 [4] in the Contact 
header field during establishment of the session associated with the SIP INVITE request due to static STN; 

then SCC AS shall apply the MSC Server assisted mid-call feature as described in subclause 9.3.2A with the following 
differences: 

1. the SCC AS shall release all the superfluous audio sessions; and 

2. the SCC AS does not initiate release for Source Access Leg of the associated SIP dialogs but remove speech 
media flow for these dialogs. 

Removing speech media flow for SIP dialogs, the SCC AS shall: 

- if the speech media flow was the only media flow in the SIP dialogs, release the source access leg as specified in 
3GPPTS 24.229 [2]; or 

if the SIP dialogs contains other media flows than the speech flow, modify the source access leg and remove the 
speech media flow, as specified in 3GPP TS 24.229 [2]. 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 



47 



ETSI TS 124 237 V9.4.0 (2010-10) 



The SCC AS shall consider session with speech: 

- which has "sendonly" or "inactive" directionality at the SC UE as inactive; and 

- which has "recvonly" or "sendrecv" directionality at the SC UE as active; 
in this subclause and in the referenced subclauses. 

1 2.3.3 SCC AS procedures for SR-VCC, abnormal case 

1 2.3.3.1 SR-VCC cancelled by MME 

When the SCC AS receives a SIP re-INVITE request containing Reason header field containing protocol "SIP" and 
reason parameter "cause" with value "487" on 

the original source access leg; or 

- if the SCC AS applies the MSC Server assisted mid-call feature, the original source access leg of the additional 
transferred session; 

after having initiated an access transfer that was triggered by a SIP INVITE request due to STN-SR and the SIP 
INVITE request due to STN-SR transaction is not yet completed then the SCC AS shall wait until this transaction has 
completed and then continue with the steps described below. 

When the SCC AS receives a SIP re-INVITE request(s) containing protocol "SIP" and reason parameter "cause" with 
value "487" after having performed an access transfer that was triggered by a SIP INVITE request due to STN-SR, then 
the SCC AS shall: 

1) not release the original access leg once the expiration of that timer as described in subclause 12.3.1; and 

2) treat the SIP re-INVITE request(s) as per procedures for removing and adding media as described in 
subclause 13.3.1. 

NOTE: The SCC AS assigns an operator specific timer to delay the release of the Source Access Leg for SR- 
VCC access transfer. 

When the SCC AS receives a SIP response to the SIP re-INVITE indicating success in removing all media components 
from a dialog that was created due to the SIP INVITE request due to STN-SR then the SCC AS shall send a SIP BYE 
request on this dialog, by following the rules of 3GPP TS 24.229 [2]. 

1 2.3.3.2 P-CSCF releasing the source access leg during SR-VCC 

When SCC AS receives a SIP BYE request on the Source Access Leg with the Reason header field containing a SIP 
503 (Service Unavailable) response code then: 

- if the SCC AS receives a SIP INVITE request due to STN-SR within a time defined by the operator policy after 
the SIP BYE request reception, then the SCC AS shall not initiate release of the Remote Leg; and 

- if the SCC AS does not receive a SIP INVITE request due to STN-SR within a time defined by the operator 
policy after the SIP BYE request reception then the SCC AS shall initiate release of the Remote Leg. 

NOTE: 8 seconds is an appropriate value for the operator policy. 

1 2.4 MSC server enhanced for ICS 

When an MSC server enhanced for ICS supporting SRVCC receives an indication for a session transfer as described in 
3GPP TS 23.216 [49], then the MSC server enhanced for ICS shall initiate a SIP INVITE request and shall: 

1) set the request URI to the STN-SR for the speech session to be transferred; 

2) set the P-Asserted-Identity header field to the Correlation MSISDN; 

3) set the Contact header field to the address of the MSC server; and 
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4) include an SDP offer with media which the MSC server wishes to use in the session. 

NOTE: MSC Servers enhanced for ICS does not apply the ICS procedure described in 3GPP TS 29.292 [18] and 
3GPP TS 24.292 [4] when sending the SIP INVITE request. 

After finishing the access transfer procedures, the MSC Server enhanced for ICS shall apply the ICS procedure as 
specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4]. 

If the MSC server supports MSC Server assisted mid-call services feature, the MSC server shall apply procedures as 
described in subclause 9.4 with following modifications: 

0. the MSC Server does not apply the ICS procedure described in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4] 
when sending the SIP INVITE request; 

1 . if two sessions are transferred, associate the SIP INVITE request for an additional inactive session with CS call 
with transaction identifier 1 and TI flag value as in mobile terminated call; and 

NOTE: The active session transaction identifier value is described in 3GPP TS 24.008 [8] 

2. if single session is transferred and all the media in the SDP answer of the SIP 2xx response to the SIP INVITE 
request have directionality inactive, associate the SIP INVITE request for the session with CS call with 
transaction identifier and TI flag value as in mobile terminated call. 

The MSC server shall consider session with audio media: 

which has "sendonly" or "inactive" directionality as inactive; and 

- which has "recvonly" or "sendrecv" directionality as active; 

in this subclause and in the referenced subclauses. 

12.5 EATF 

1 2.5.1 EATF procedures for PS to CS session continuity, E-SR-VCC 

The EATF needs to distinguish between the following initial SIP INVITE requests to provide specific functionality for 
E-SR-VCC: 

1. SIP INVITE request routed to the EATF due to E-STN-SR in the Request-URI. In the procedures below, such 
requests are known as "SIP INVITE requests due to E-STN-SR". 

NOTE: The same E-STN-SR is used for all the emergency session access transfers within one PLMN. 

Other initial SIP requests can be dealt with in any manner conformant with 3GPP TS 24.229 [2]. 

When the EATF receives a SIP INVITE request due to E-STN-SR on the Target Access Leg, the EATF shall: 

1. associate the SIP INVITE request due to E-STN-SR with a source access leg, i.e. an existing SIP session 
anchored at the EATF with the instance-id media feature tag provided by the SC UE in the Contact header field 
at session establishment equal to the instance-id media feature tag included in the Contact header field of the 
received SIP INVITE request. If no source access leg exists or if multiple source access legs exist, then the 
EATF shall send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to E-STN- 
SR; and 

2. originate session modification as described in 3GPP TS 24.229 [2] towards the remote UE with a new SDP offer 
with media characteristics as received in the SIP INVITE request due to E-STN-SR. 

Upon receiving the SIP ACK request from the Target Access Leg, the EATF shall release the source access leg as 
described in 3GPP TS 24.229 [2]. 
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12.6 MSC server enhanced for SRVCC using SIP interface 

1 2.6.1 Session transfer from MSC server enhanced for SRVCC using SIP 
interface 

When an MSC server enhanced for SRVCC using SIP interface receives an indication for a session transfer as described 
in 3GPP TS 23.216 [49], then the MSC server enhanced for SRVCC using SIP interface shall initiate a SIP INVITE 
request and shall: 

1) set the request URI to the STN-SR for the speech session to be transferred; 

2) set the P-Asserted-Identity header field to the Correlation MSISDN; 

3) set the Contact header field to the address of the MSC server; and 

4) include an SDP offer with media which the MSC server wishes to use in the session. 

If the MSC server enhanced for SRVCC using SIP interface applies the MSC Server assisted mid-call features then in 
addition to the procedures in this subclause it shall support the procedures defined in subclause 12.4. 

1 2.6.2 Emergency session transfer from MSC server enhanced for SRVCC 
using SIP interface 

When an MSC server enhanced for SRVCC using SIP interface receives an indication for a session transfer for an 
emergency session as described in 3GPP TS 23.216 [49], then the MSC server enhanced for SRVCC using SIP 
interface shall initiate a SIP INVITE request and shall: 

1) set the request URI to the E-STN-SR for the speech session to be transferred; 

2) include the instance-id feature tag as specified in IETF RFC 5626 [22] with a value based on the IMEI as defined 
in 3GPP TS 23.003 [12] in the Contact header field; 

3) set the P-Asserted-Identity header field to the Correlation MSISDN if one is available; and 

4) include an SDP offer with media which the MSC server wishes to use in the session. 

1 3 Roles for media adding/deleting for access transfer 

13.1 Introduction 

This clause specifies the procedures for adding or deleting media to an existing multimedia session. Procedures are 
specified for the SC UE and the SCC AS. 

13.2 SCUE 

1 3.2.1 Adding or removing media through Gm 

If the SC UE wants to add or remove media components to a session that was previously established using Gm 
reference point, the SC UE shall follow the procedures defined in 3GPP TS 24.229 [2] for adding/removing PS media. 

If the SC UE wants to transfer media components from the source access leg to an existing target access leg (i.e the 
access legs were previously established due to the partial session transfer) using Gm reference point, the SC UE shall: 

1. add the media components to the target access leg; and 

2. remove those media components from the source access leg, 
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by using procedures defined in 3GPP TS 24.229 [2] for adding/removing PS media. 

If SC using ICS is enabled then if the SC UE wants to add or remove CS media components to a session, it shall follow 
the procedures defined in 3GPP TS 24.292 [4]. 

If the SC UE receives a SIP re-INVITE request or a SIP UPDATE request from the remote UE to add or remove media 
components to a session that was previously established using Gm, the SC UE shall follow the procedures defined in 
3GPP TS 24.229 [2] for adding or removing PS media and shall follow the procedures defined in 3GPP TS 24.292 [4] 
for adding or removing CS media to the session. 

1 3.2.2 Adding Gm control to existing CS session 

The SC UE shall add Gm control to an existing CS session only when there is a single full-duplex speech session over 
CS. If there is more than one full-duplex speech session, the SC UE shall release all the ongoing sessions that are not 
currently active before attempting the procedures described in this section. 

If the SC UE wants to add Gm control to an existing CS session that was established without Gm, after registering with 
the IM CN subsystem, the SC UE shall send an initial SIP INVITE request over the PS access in accordance with 
3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as follows: 

- set the Request-URI to the static STI; and 

- set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing an audio 
stream over a circuit switched bearer. The SC UE can optionally include additional PS media to the SDP in 
accordance to the procedures defined in 3GPP TS 24.229 [2]. 

Upon receiving a SIP 200 (OK) response, the SC UE shall treat the ongoing CS call as established using Gm and shall 
follow the "ICS UE using Gm" procedures defined in 3 GPP TS 24.292 [4] for controlling the CS call. 

If the SC UE receives a new SIP INVITE request containing an audio stream over a circuit-switched bearer in the SDP 
and the SCC AS PSI DN matches the B-party number of the ongoing CS call that was established without Gm, the SC 
UE shall: 

- respond to the SIP INVITE request in accordance with the procedures defined in 3GPP TS 24.292 [4]; and 

- treat the ongoing CS call as established using Gm and shall follow the "ICS UE using Gm" procedures defined in 
3GPP TS 24.292 [4] for controlling the CS call. 

13.3 SCC AS 

1 3.3.1 Adding or removing media through Gm 

If the SCC AS receives a SIP re-INVITE request or a SIP UPDATE request from the SC UE, in which already existing 
media components of the session are transferred from a source access leg to an already existing target access leg (i.e. 
the target access leg was already established due to partial session transfer), the SCC AS shall update the remote UE 
using the session transfer procedures defined in subclause 10.3.2. 

NOTE: The SC UE indicates that media is switched from the source access leg to the target access leg by using the 
procedures defined in 3GPP TS 24.229 [2] for adding / removing PS media, i.e. the related connection and port 
information of the transferred media component within the SDP is changed from the source access leg to the target 
access leg. 

If the SCC AS receives a SIP re-INVITE request or a SIP UPDATE request from the SC UE or remote UE to 
add/remove new media components, to an existing access leg of the session established using Gm, the SCC AS shall 
follow the procedures defined in 3GPP TS 24.229 [2] for adding or removing PS media and shall follow the procedures 
defined in 3GPP TS 24.292 [4] for adding or removing CS media to the session. 

1 3.3.2 Adding Gm control to existing CS session 

If the SCC AS receives a SIP INVITE request containing the static STI in the Request-URI the SCC AS shall determine 
if this SIP INVITE request is for an ongoing call by determining if the received contents of SIP INVITE request's 
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Contact header field is bound to an ongoing CS call session identifier. If the SC UE has an ongoing CS call, the SCC 
AS shall: 

respond to the SIP INVITE request in accordance with the procedures defined in 3GPP TS 24.292 [4]; 

- treat the ongoing CS call as established using Gm and shall follow the "SCC AS for service control over Gm" 
procedures defined in 3GPP TS 24.292 [4] for controlling the CS call; and 

- if the SIP INVITE request contains additional PS media, the SCC AS shall send a SIP re-INVITE request 
towards the remote UE, including the newly added PS media, in accordance with the procedures defined in 
3GPPTS 24.229 [2]. 

The SCC AS shall add Gm control to an existing CS session only when there is a single full-duplex speech session over 
CS. If the SCC AS wants to add Gm control to an existing CS session that was established without Gm, the SCC AS 
shall send a new SIP INVITE request over the PS access in accordance with 3GPP TS 24.229 [2]. The SCC AS shall 
populate the SIP INVITE request as follows: 

- set the Request-URI to the public user identity of the UE; and 

- set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing an audio 
stream over a circuit switched bearer. 

Upon receiving a SIP 200 (OK) response, the SCC AS shall treat the ongoing CS call as established using Gm and shall 
follow the "SCC AS for service control over Gm" procedures defined in 3GPP TS 24.292 [4] for controlling the CS 
call. 



1 4 Roles for UE discovery for inter-UE transfer 

14.1 Introduction 

This clause specifies the target UE discovery procedures for UEs that are candidate UEs for inter UE transfer. The list 
of candidate UEs is a contact list such as name of the UE, which is represented in SIP through the use of SIP contact or 
the instance-id. The subscription of candidate UEs may be configured such that the private user identities associated 
with the UEs involved in inter UE transfer share the same set of implicitly registered public user identities. 

14.2 SCUE 

The target UE discovery procedures include the registration status (active, inactive), and the UE capabilities (e.g. 
support of audio/video formats etc.). 

In order to determine a list of UEs sharing the same set of implicitly registered public user identities and their capability 
information, the SC UE subscribes to the reg-event package as described in 3GPP TS 24.229 [2] in subclause 5.1.1.3. 

NOTE 1 : In order to allow inter UE transfer to UEs belonging to the same user subscription but belonging to a 
different set of implicitly registered public user identities, a user can have a static list of UEs that is 
manually administered by the user and stored locally in the user's device (e.g. phone book). Having a 
static list is an implementation in the UE and has no impact on the standards. 

NOTE 2: If the UE is not part of the same set of implicitly registered public user identities as the SC UE, or if the 
SC UE was unable to obtain the capability information of the UE through the use of reg-event package, 
the SC UE can send a SIP OPTIONS request to the UE to attempt to retrieve capability information. In 
order to avoid a lot of transactions, a SIP OPTIONS request is generated based on an action initiated by 
the user (e.g. after the user has finished adding a new UE in the static list, or the user explicitly asks for 
getting UE capability information). 
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14.3 SCC AS 

The information of UEs that belong to the same subscription is required at the SCC AS for the purpose of authorizing 
that the requested inter UE transfer to the UE is allowed, i.e. to prevent the SC UE from performing Inter UE Transfer 
to a UE with a different user subscription. 

The SCC AS obtains all the public user identities associated with the user's subscription from the Sh interface as 
specified in 3GPP TS 29.328 [6] and 3GPP TS 29.329 [7]. 

NOTE 1: Getting the public user identities over the Sh interface allows the SCC AS to receive information of UEs 
sharing the same set of implicitly registered public user identities and information of UEs within the same 
user subscription that are not in the same set of implicitly registered public user identities. This is needed 
to authorize the static list of UEs that is manually administered by the user and stored locally in the user's 
device. 

The SCC AS can obtain the registration information (e.g. GRUU) by the following methods: 

1. using the 3rd-party SIP REGISTER request as described in 3 GPP TS 24.229 [2] in subclause 5.4.1.7; or 

2. the SCC AS subscribes to the reg-event package as described in 3GPP TS 24.229 [2] in subclause 5.4.2.1.1. 

NOTE 2: The SCC AS needs to know the public user identity for the authorization of the SIP REFER request for 
inter UE transfer. To get the public user identity from the public GRUU, the SCC AS can simply remove 
the "gr" parameter from the public GRUU. Using the 3rd-party registration or subscribing to the reg-event 
package allows the SCC AS to find the temporary GRUU of the UE and to correlate the GRUU with the 
public user identities. After correlation, the SCC AS would make a list of GRUUs that are associated with 
the same subscription and/or with the same set of implicitly registered public user identities. 



1 5 Roles for inter-UE transfer without establishment of 
collaborative session 

15.1 Introduction 

This clause specifies the procedures for transferring all media of an existing session from one UE to another UE of the 
same subscriber. Procedures are specified for the transferor SC UE, the transferee SC UE and the SCC AS. 

15.2 SCUE 

1 5.2.1 Transferor SC UE in services defining only originating session set 
up in UE 

In order to transfer all media of an existing session from this SC UE to another UE that shares the same user 
subscription, the SC UE shall send a SIP REFER request as specified in IETF RFC 3515 [13] and in accordance with 
UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP REFER request as follows: 

1 . the Request-URI set to the URI of the UE where the session is to be transferred to; 

NOTE: The URI of the UE needs to be a GRUU if several UEs share the same public user identity. 

2. the Refer-To header field set to the Inter UE Transfer SCC AS URI and extended with the following URI header 
fields: 

A. if usage of SIP Replaces extension is selected: 

a. the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier 
of the Access Leg between this UE and the SCC AS; and 

b. the Require header field populated with the option tag value "replaces"; 
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B. if usage of SIP Target-Dialog extension is selected: 

a. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the Access Leg between this UE and the SCC AS; and 

b. the Require header field populated with the option tag value "tdialog"; and 

C. if the session is established using an IMS communication service that requires the use of an IMS 
communication service identifier: 

a. optionally the Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the IMS 
communication service identifier of the existing session; and 

b. the P-Preferred-Service header field set to the IMS communication service identifier of the existing 
session; and 

3. the Contact header field: including a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2]. 

If the SC UE receives any SIP 4xx, SIP 5xx, or SIP 6xx response to the SIP REFER request or if the SC UE receives a 
SIP NOTIFY request containing a message/sipfrag body of any SIP 4xx, SIP 5xx or SIP 6xx response, then the inter UE 
transfer has not completed successfully. 

1 5.2.2 Transferee SC UE in services defining only originating session set 
up in UE 

When sending a SIP INVITE request upon SIP REFER request reception in accordance with UE procedures specified in 
3GPP TS 24.229 [2] and IETF RFC 3515 [13], the SC UE shall populate the SIP INVITE request with header fields 
which were included as URI header fields in the URI in the Refer-To header field of the received SIP REFER request. 

15.3 SCC AS 

1 5.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following SIP requests to provide specific functionality relating to inter 
UE transfer: 

1 . SIP INVITE request routed to the SCC AS upon originating or terminating filter criteria containing the Inter UE 
Transfer SCC AS URI in the Request-URI and a STI belonging to the same user subscription in: 

A. the Target-Dialog header field; or 

B. in the Replaces header field 

with at least one offered media type used in session by a UE other than the UE identified by the Contact header 
field value. Then in the procedures below, such a request is known as "SIP INVITE request due to inter UE 
transfer". 

2. SIP REFER request routed to the SCC AS due to the originating filter criteria where: 

A. the GRUU in the Contact header field identifies a UE of the user identified in P-Asserted-Identity header 
field; 

B. the GRUU in the Contact header field identifies a UE of the same user subscription as the SIP URI in the 
Request-URI; 

C. the dialog identifier in: 

a. the Replaces URI header field of the URI in the Refer-To header field; or 

b. the Target-Dialog URI header field of the URI in the Refer-To header field; 
belongs to a session of the UE identified by the GRUU in the Contact header field; and 
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D. the Refer-To header field contains the Inter UE Transfer SCC AS URI either without method parameter or 
with method parameter set to "INVITE". 

Then in the procedures below, such a request is known as "SIP REFER request due to inter UE transfer". 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 5.3.2 Inter UE transfer request authorization in services defining only 
originating session set up in UE 

Upon receiving a SIP REFER requests due to inter UE transfer, the SCC AS shall: 

1. reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps if: 

A. the media streams of the session, one leg of which is identified by the dialog identifier in: 

a. the Replaces URI header field of the URI in the Refer-To header field; or 

b. the Target-Dialog URI header field of the URI in the Refer-To header field; 
are delivered to two or more UEs of the same user subscription; or 

B. at least one media stream of the session identified by the dialog identifier in: 

a. the Replaces URI header field of the URI in the Refer-To header field; or 

b. the Target-Dialog URI header field of the URI in the Refer-To header field 

is delivered to a UE other than the UE identified by the GRUU in the Contact header field; 

2. insert a Record-Route header field with SCC AS own address; and 

3. forward the SIP REFER request in any manner conformant with 3GPP TS 24.229 [2]. 

The SCC AS shall forward the SIP response to the SIP REFER request, the associated SIP NOTIFY request, and the 
SIP response to the NOTIFY request conformant with 3GPP TS 24.229 [2]. 

1 5.3.3 SCC AS procedures for inter UE transfer in services defining only 
originating session set up in UE 

Upon receiving a SIP INVITE request due to inter UE transfer, the SCC AS shall: 

1. reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps if: 

A. the SCC AS is not aware of a subscription created by a SIP REFER request with the dialog identifiers: 

a. in the Replaces header field of the received SIP INVITE request and in the Replaces URI header field of 
the URI in the Refer-To header field of the SIP REFER request are equal; or 

b. in the Target-Dialog header field of the received SIP INVITE request and in the Target-Dialog URI 
header field of the URI in the Refer-To header field of the SIP REFER request are equal; 

2. associate the received SIP INVITE request with an ongoing SIP dialog by matching the dialog identifier in the 
Replaces header field or the Target-Dialog header field. By an ongoing SIP dialog, it is meant a dialog for which 
a SIP 2xx response to the initial SIP INVITE request has been sent or received; 

3. if a dialog identifier is not included in either in the Replaces header field or in the Target-Dialog header field or 
if the included dialog identifier does not identify an existing ongoing dialog, send a SIP 480 (Temporarily 
Unavailable) response to reject the SIP INVITE request and not processes the remaining steps; 

4. identify the Source Access Leg by the dialog identifier present in the Replaces or the Target-Dialog header field 
of the SIP INVITE request; 
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5. if a media type used in the Source Access Leg session is not offered in the SDP offer of the SIP INVITE request 
then reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps; 

6. if the SIP INVITE request contains a Replaces header field: 

A. follow the procedures defined in IETF RFC 3891 [10] for replacing the Source Access Leg with the SIP 
request received on the Target Access Leg, including terminating the Source Access Leg by sending a SIP 
BYE towards the SC UE in accordance with 3GPP TS 24.229 [2]; and 

7. send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS shall 
populate the SIP re-INVITE request as follows: 

A. include a new SDP offer including the media characteristics as received in the SIP INVITE request, by 
following the rules of the 3GPP TS 24.229 [2]; and 

B. set the Contact header field to the Contact header field value recieved in the SIP INVITE request. 

Upon receiving the SIP ACK request originated from the SC UE, the SCC AS shall initiate release of the Source Access 
Leg by sending a SIP BYE towards the SC UE in accordance with 3GPP TS 24.229 [2]. 

1 6 Roles for collaborative session establishment for 
inter-UE transfer 

16.1 Introduction 

This clause specifies the roles of controller UE, controllee UE and the SCC AS when controller UE transfers media 
used in an existing session to a controllee UE or adds a new media to an existing session on the controllee UE. 

16.2 SCUE 

1 6.2.1 SC UE procedures for collaborative session establishment by 
transferring media used in an existing session 

1 6.2.1 .1 Controller UE procedures 

To establish a collaborative session by transferring one or more media components, the controller UE shall send a SIP 
REFER request outside the existing dialog as specified in IETF RFC 3515 [13] and include: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header field set as follows: 

a) the SIP URI of the controllee UE; 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) lines in the session set as follows: 

- media lines that are not being transferred with the port number set to zero 

- media line(s) that are to be transferred containing the port number for the corresponding media types 
received in the media line of the SDP received during the last successful SDP offer/answer exchange; 

3) the Accept header field containing the MIME type "message/sipfrag"; 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session 
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5) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex C;and 

6) the Referred-By header field containing a currently registered public user identity of the user to be delivered to 
the controllee UE. 

The controller UE shall handle any response to the SIP REFER request and the subsequent SIP NOTIFY requests 
according to 3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The controller UE shall save the media information (i.e. 
media type(s) and port number(s)) related to the transferred media component(s) received in the sipfrag body of the SIP 
NOTIFY requests in order to perform further inter-UE transfer operations on the controllee UE. When the controller UE 
receives a SIP re-INVITE request from the SCC AS to update the status of the transferred media component after a 
successful transfer, the controller UE shall follow the procedures described in 3GPP TS 24.229 [2], including in the 
Contact header field of the SIP 200 (OK) response the g.3gpp.iut-controller media feature tag as described in annex C. 

If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx 
final response, the controller UE shall consider the transfer operation failed and continue the existing session with 
media components prior to the failed transfer attempt. 

1 6.2.1 .2 Controllee UE procedures 

There are no specific procedures for the controllee UE for the collaborative session establishment by transferring media, 
besides the procedures described in 3GPP TS 24.229 [2]. 

1 6.2.2 SC UE procedures for collaborative session establishment with new 
media 

1 6.2.2.1 Controller UE procedures 

The controller UE may establish a collaborative session with a new media at anytime while it has an ongoing IMS 
established session according to 3GPP TS 24.229 [2] with a remote UE. 

The controller UE shall add the new media by sending a SIP REFER request outside the existing dialog as specified in 
IETF RFC 3515 [13] and include: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header field set as follows: 

a) the SIP URI of the controllee UE; 

NOTE 1 : The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and other UEs share the same 
public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) lines in the session set as follows: 

- media lines that are not being transferred with the port number set to zero 

- media line(s )that are to be added containing the media type(s) to be added and the discard port number 
"9" 

NOTE 2: The discard port number "9" indicates that this port number should be ignored. 

3) the Accept header field containing the MIME type "message/sipfrag"; 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session 

5) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex C;and 

6) the Referred-By header field containing a currently registered public user identity of the user to be delivered to 
the controllee UE. 

The controller UE shall handle any response to the SIP REFER request and the subsequent SIP NOTIFY requests 
according to 3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The controller UE shall save the media information (i.e. 
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media type(s) and port number(s)) received in the sipfrag body of the SIP NOTIFY requests in order to perform further 
inter-UE transfer operations on the controllee UE. 

If error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx final 
response, the controller UE shall consider the transfer operation failed and continue the existing session with media 
components prior to the failed transfer attempt. 

The controller UE may also receive SIP NOTIFY requests as the results from the SIP SUBSCRIBE request to the 
dialog event package between itself and the SCC AS as described in clause 21. The controller UE shall save the media 
information (i.e. media type(s) and port number(s)) received in the body of the SIP NOTIFY requests in order to 
perform further inter-UE transfer operations on the controllee UE. 

16.2.2.2 Controllee UE procedures 

There are no specific procedures for the controllee UE for the collaborative session establishment by adding media, 
besides the procedures described in 3GPP TS 24.229 [2]. 

16.2.3 Void 
16.3 SCC AS 

1 6.3.1 Distinction of requests sent to the SCC AS 

The SCC AS needs to distinguish between the following initial SIP REFER requests to provide specific functionality 
relating to the call origination: 

1) SIP REFER requests routed to the SCC AS containing: 

a) the Inter UE Transfer SCC AS URI in the Request-URI; 

b) the Target-Dialog header field with dialog identifier identifying an existing session owned by the UE sending 
the SIP REFER request; and 

c) the Refer-To header field containing a SIP URI: 

i) of a UE which is neither the UE which sent the SIP REFER request, nor the remote UE, but which is 
within the list of UEs which can be involved within an collaborative session with the UE which originated 
the SIP REFER request; 

ii) with the SIP URI containing the URI header field with the hname "body" containing SDP for the media 
lines with media types for at least all the media components of the existing session with one or more 
media lines not used in the existing session and indicated with the discard port value 9; and 

iii) without method parameter or with method parameter set to "INVITE". 

In the procedures below, such SIP REFER requests are called "SIP REFER requests for establishing new media 
at controllee UE". 

NOTE 1: It is assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the 
request from the UE. 

2) SIP REFER requests routed to the SCC AS containing: 

a) the Inter UE Transfer SCC AS URI in the Request-URI; 

b) the Target-Dialog header field with dialog identifier identifying an existing session owned by the UE sending 
the SIP REFER request; and 

c) the Refer-To header field containing a SIP URI: 
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i) of a UE which is neither the UE which sent the SIP REFER request, nor the remote UE, but which is 
within the list of UEs which can be involved within an collaborative session with the UE which originated 
the SIP REFER request; 

ii) with the hname "body" URI header field containing SDP for the media lines with media types for all the 
media components of the existing session with one or more media lines used in the existing session and 
listed with non zero port value; and 

iii) without method parameter or with method parameter set to "INVITE". 

In the procedures below, such SIP REFER requests are called "SIP REFER requests for transferring an existing 
media to controllee UE". 

NOTE 2: It is assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the 
request from the UE. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction are handled conformant with 
3GPPTS 24.229 [8]. 

1 6.3.2 SCC AS procedures for collaborative session establishment by 
transferring media 

NOTE: If the controller UE is already involved in a collaborative session then the procedures in 
subclause 17.13.1 apply. 

When the SCC AS establishes a collaborative session by transferring media as a result of receiving a SIP REFER 
request for transferring an existing media type to a controllee UE from the controller UE , the SCC AS shall send: 

1) a SIP 202 (Accepted) response to the SIP REFER request and a SIP NOTIFY request containing a sipfrag "SIP 
100 Trying" to the controller UE as specified in IETF RFC 3515 [13]; and 

2) a SIP INVITE request to controllee UE, containing: 

a) Request-URI with SIP URI from the Refer-To header field of the received SIP REFER request; 

b) the Referred-By header field containing the values from the Referred-By header field of the received SIP 
REFER request according to the procedures of RFC 3892 [59]; 

c) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from the remote UE at the original session establishment; and 

d) the SDP information for the media component to be transferred as follows: 

A) The media type(s) from the media (m=) lines from the hname "body" URI header field in the SIP URI in 
the Refer-To header field of the received SIP REFER request; and 

B) for media lines which have non zero port numbers the SDP parameters from the corresponding media 
lines as received during the last successful SDP offer/answer exchange from the remote UE and extended 
with 

i) sendonly directionality; and 

ii) bandwidth information with RS set to zero and RR set to zero. 

If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort 
the media transfer and establishment of the collaborative session and continue the existing session with media 
components prior to the failed transfer attempt. 

If the SIP final response was a SIP 2xx response containing a SDP answer, the SCC AC shall send a SIP re-INVITE 
request on the dialog for the remote leg to the remote UE as specified in 3GPP TS 24.229 [2]. The SCC AS shall: 

1) send a SIP re-INVITE request containing SDP information as follows: 
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a) for the transferred media component(s), set the SDP information as from the SDP answer received in the SIP 
200 (OK) response from the controllee UE with the difference that the directionality is set to directionality 
used by the controller UE; and 

b) for all other media components in the collaborative session, include the SDP information as from the original 
session to the remote leg. 

Upon receipt of a 2xx response for the re-INVITE request sent to the remote UE, the SCC AS shall: 

1) send a SIP re-INVITE request to the controller UE following the procedures described in 3GPP TS 24.229 [2] to 
remove the media for the transferred media component. 

Upon receiving a SIP 200 (OK) response with the SDP answer on the remote leg, the SCC AS shall send a SIP ACK 
request on the remote leg. 

Upon receipt of a 2xx response for the re-INVITE request sent to the controller UE, the SCC AS shall send a SIP re- 
INVITE request to the controllee UE following the procedures described in 3GPP TS 24.229 [2] and set the 
directionality (i.e. sendrecv/sendonly/recvonly/inactive) attributes associated to the transferred media component to 
according to the SDP answer received from the remote UE. 

Upon receiving a final response to the SIP re-INVITE request which was sent towards the controllee UE to set the 
directionality attributes associated to the transferred media component, the SCC AS shall: 

1) send a SIP NOTIFY request containing the received final response code in the sipfrag body to the controller UE; 

2) if the received response to the SIP re-INVITE is a SIP 2xx response containing an SDP answer, then include 
within the sipfrag body 

a) the Content-Type header field from the received SIP 2xx response; and 

b) the SDP answer received in the SIP 2xx response. 

1 6.3.3 SCC AS procedures for collaborative session establishment with 
new media 

When SCC AS receives a SIP REFER request in a new dialog from the contoller UE for establishing a collaborative 
session by adding new media to the controllee UE, the SCC AS shall send: 

1) a SIP 202 (Accepted) response to the controller UE; 

2) a SIP NOTIFY request containing a sipfrag "SIP 100 Trying" as described in IETF RFC 3515 [13] to the 
controller UE; and 

3) a SIP INVITE request in accordance to 3GPP TS 24.229 [2] to the controllee UE. The SCC AS shall construct 
the SIP INVITE request as follows: 

a) Request-URI set to the SIP URI from the Refer-To header field of the received SIP REFER request; 

b) the Referred-By header field containing the values from Referred-By header field of the received SIP REFER 
request if authorized by SCC AS, according to the procedures of the RFC 3892 [59]; 

c) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from the remote UE at the original session establishment; and 

d) includes an SDP offer: 

A) with the media type(s) from the media (m=) lines in the same order as in the hname "body" URI header 
field of the SIP URI in the Refer-To header field of the received SIP REFER request; 

B) with port numbers of the media line(s) set to zero except the media line(s) of the new media, i.e. the 
media line(s): 

i) which were listed in the received SDP of the SIP REFER request with the discard port number "9"; 
and 
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ii) which are not used yet in the session; and 

C) for the media line(s) containing the media type(s) of the new media component(s) with additional SDP 
fields containing: 

i) sendonly directionality; 

ii) bandwidth information with RS set to zero and RR set to zero; and 

iii) a c-line set to the unspecified address (0.0.0.0) if IPv4 or a domain name within the ".invalid" DNS 
top-level domain in case of IPv6 as described in draft-ietf-sipping-v6-transition [56]. 

If a SIP non-2xx final response is received from the controllee UE, the SCC AS shall send a SIP NOTIFY request 
including the SIP final response as a sipfrag body to the controller UE and consider the inter-UE transfer operation 
failed. Otherwise, the SCC AS continues with the remainder of the steps described in this subclause. 

Upon receiving a SIP 2xx response from the controllee UE with an SDP answer, the SCC AS shall send a SIP re- 
INVITE request to the remote UE as specified in 3GPP TS 24.229 [2]. The SCC AS shall construct the SDP offer in the 
SIP re-INVITE request as follows: 

1) the SDP information as follows: 

a) for the added media component(s), set the SDP information as from the SDP answer received in the SIP 200 
(OK) response from the controllee UE with the difference that the directionality is set to sendrecv 
directionality; and 

b) for all other media components in the collaborative session, include the SDP information as from the original 
session to the remote leg. 

If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort 
the media transfer and establishment of the collaborative session. 

If the SIP final response from the remote UE was a SIP 2xx response with the SDP answer, the SCC AS shall: 

1) send to the remote UE a SIP ACK request; and 

2) send to the controllee UE a SIP re-INVITE request containing the current port number for the media component 
to be added and set the directionality (i.e. sendrecv/sendonly/recvonly/inactive) attributes associated to the 
transferred media component to according to the SDP answer received from the remote UE. 

NOTE 0: This SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 

was generated by the SCC AS due to third party call control to allow sending this SIP re-INVITE request. 

NOTE 1 : Any other changes such as IP address of the remote leg in case remote leg uses different IP addresses for 
different media components can also be updated in the SIP re-INVITE request. 

Upon successful completion of the SDP offer answer exchange using SIP re-INVITE request with the controllee UE, 
the SCC AS shall: 

1) send to the controllee UE a SIP ACK request 

Upon receiving a SIP final response from the controllee UE, the SCC AS shall send, a SIP NOTIFY request containing 
the received final response code in the sipfrag body and if the received response was a SIP 200 (OK) response 
containing an SDP answer then also include in the sipfrag the Content-Type header field from the received 200 (OK) 
response along with the media (m=) line(s) from the SDP answer. 
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16.3.4 Void 

16.3.5 Void 

1 7 Roles for media transfer within collaborative session 
for inter-UE transfer 

17.1 Introduction 

This clause specifies the roles of the controller UE, the controllee UE and the SCC AS when media transfer from the 
controller UE to a controllee UE or from a controllee UE to another controllee UE within a collaborative session. 

17.2 SCUE 

1 7.2.1 Procedures for controller UE initiated media transfer from controller 
UE to controllee UE 

1 7.2.1 .1 Controller UE procedures 

The SC UE procedures for media transfer from controller UE to a controllee UE is the same as the procedures described 
in subclause 16.2.1.1 with exception that the controller UE asets the port numbers for the media types of the media 
components (in the hname "body" URI header field from the SIP URI in the Refer-To header field of the SIP REFER 
request) which are being transferred to the controllee UE to values from the corresponding media lines received during 
the last successful SDP offer and answer exchange with the remote party. 

1 7.2.1 .2 Controllee UE procedures 

There are no specific procedures for the controllee UE for media transfer from controller UE to controllee, besides the 
procedures described in 3GPP TS 24.229 [2]. 

1 7.2.2 Procedures for controller UE initiated media transfer from controllee 
UE to another controllee UE 

17.2.2.1 Controller UE procedures 

To transfer a media component within a collaborative session from one controllee UE to another controllee UE, the 
controller UE shall send a SIP REFER request outside the existing dialog as specified in IETF RFC 3515 [13] and 
include: 

1) the Request-URI set to the Inter UE Transfer SCC AS; 

2) the Refer-To header field set as follows: 

a) the SIP URI of the controllee UE to which the media m-lines are to be transferred; and 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) lines in the session set as follows: 

- media lines which are not served by the target controllee UE and which are not being transferred with the 
port numbers set to zero; 
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media lines which are already served by the target controllee UE, therefore are not to be transferred 
containing the port numbers of the remote UE; and 

media line(s) which are to be transferred containing the port numbers of the remote UE. 

3) the Accept header field containing the MIME type "message/sipfrag"; 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the collaborative session; and 

5) the Referred-By header field containing a currently registered public user identity of the user to be delivered to 
the controllee UE; and. 

6) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex C. 

The controller UE shall handle the subsequent SIP NOTIFY requests to the SIP REFER request according to 
3GPP TS 24.229 [2], IETF RFC 3515 [13]. 

The controller UE shall save the media information (i.e. media types(s) and port number(s)) related to the media 
component(s) received in the sipfrag body of the SIP NOTIFY requests in order to perform further inter-UE transfer 
operations on the controllee UE. 

If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx 
final response, the controller UE shall consider the transfer operation failed and continue the existing session with 
media components prior to the failed transfer attempt. 

1 7.2.2.2 Controllee UE procedures 

There are no specific procedures for the controllee UE for transferring media form one controllee UE to another 
controllee UE, besides the procedures described in 3GPP TS 24.229 [2]. 

17.3 SCC AS 

1 7.3.1 Procedures for controller UE initiated media transfer from controller 
UE to controllee UE 

The SCC AS procedures for media transfer from the controller UE to a controllee UE is the same as the procedures 
described in subclause 16.3.2 with the exception that upon receipt of a SIP REFER request from the controller UE the 
SCC AS sends a SIP re-INVITE request instead of a SIP INVITE request to the controllee UE. The SIP re-INVITE 
request is within the dialog established when establishing the collaborative session with the controllee UE. 

1 7.3.2 Procedures for controller UE initiated media transfer from controllee 
UE to another controllee UE 

When the SCC AS maintaining a collaborative session and transferring media as a result of receiving a SIP REFER 
request for transferring one ore more media components from one controllee UE to another controllee UE, the SCC AS 
shall send: 

1) a SIP 202 (Accepted) response to the SIP REFER request and a SIP NOTIFY request containing a sipfrag "SIP 
100 Trying" to the controller UE as specified in IETF RFC 3515 [13] for the dialog on which the SIP REFER 
request was received; and 

2) a SIP re-INVITE request to controllee UE, to which the media component(s) is to be transferred, containing the 
SDP information for the media component to be transferred as follows: 

a) the media type(s) from the media (m=) lines from the hname "body" URI header field from the SIP URI in 
the Refer-To header field of the received SIP REFER request including the associated attributes (a) set to 
sendonly and the associated bandwidth information (b) with RS set to zero and RR set to zero for those 
media compontents which are to be transferred to the target controllee UE; and 

b) for media lines which have non zero port numbers the SDP parameters from the corresponding media lines as 
received during the last successful SDP offer-answer exchange from the remote UE. 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 



63 



ETSI TS 124 237 V9.4.0 (2010-10) 



Upon receipt of a 2xx response for the re-INVITE request sent to the controllee UE to which the media component is to 
be transferred, the SCC AS shall: 

1) send a SIP re-INVITE request to controllee UE, from which the media component(s) is to be transferred, 
containing the SDP information for the media component to be transferred as follows 

a) the media type(s) from the media (m=) lines from the hname "body" URI header field from the SIP URI in 
the Refer-To header field of the received SIP REFER request including the associated attributes (a) set to 
sendonly and the associated bandwidth information (b) with RS set to zero and RR set to zero for those 
media components which are to be transferred to the target controllee UE; and 

b) for media line(s) which have non zero port numbers the SDP parameters from the corresponding media lines 
as received during the last successful SDP offer-answer exchange from the remote UE;and 

2) the Referred-By header field containing the values from the Referred-By header field of the received SIP 
REFER request according to the procedures of RFC 3892 [59]. 

NOTE 1: This SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 

was generated by the SCC AS due to third party call control to allow sending this SIP re-INVITE request. 

If a 2xx response was received to the re-INVITE request sent to the controllee UE from which the media component(s) 
is to be transferred, the SCC AC shall send a SIP re-INVITE request to the remote UE containing an SDP body as 
follows: 

1) for the transferred media component(s), set the SDP information as received from the SDP answer in the SIP 2xx 
response from the controllee UE to which the media component is to be transferred with the difference that the 
attributes (a) is set to directionality used by the controlee UE from which the media component was transferred; 

2) for all other media components in the collaborative session, include the associated media line(s) as from the 
original session to the remote leg. 

Upon receipt of a 2xx response for the re-INVITE request sent to the remote UE, the SCC AS shall: 

1) if the transferred media component was the only media component active at the controllee UE from which the 
media component was transferred from, send a SIP BYE request to the controllee UE from which the media 
component was transferred from; or 

2) if after the transfer of the media component the controllee UE from which the media was transferred from still 
has other media components within the collaborative session, send a SIP re-INVITE request to the controllee 
UE, from which the media component was transferred, following the procedures described in 

3GPP TS 24.229 [2] and set the port value of the associated media type(s) for the transferred media to zero. 

Upon receipt of a 2xx response for the re-INVITE request or the SIP BYE request sent to the controllee UE from which 
the media component was transferred the SCC AS shall send a SIP re-INVITE request to the controllee UE to which the 
media component was transferred following the procedures described in 3GPP TS 24.229 [2] and set the directionality 
(i.e. sendrecv/sendonly/recvonly/inactive) attributes associated to the transferred media component to according to the 
SDP answer received from the remote UE. 

Upon receiving a final response to the SIP re-INVITE request which was sent towards the controllee UE to set the 
directionality attributes associated to the transferred media component, the SCC AS shall: 

1) send a SIP NOTIFY request containing the received final response code in the sipfrag body to the controller UE; 

2) if the received response to the SIP re-INVITE is a SIP 2xx response containing an SDP answer, include within 
the sipfrag body 

a) the Content-Type header field from the received SIP 2xx response; and 

b) the SDP answer as received in the SIP 2xx response. 

If any final response to a SIP re-INVITE request (apart from the SIP re-INVITE request which was sent towards the 
controllee UE to set the attributes (a) associated to the transferred media component to its previous status) was a 3xx or 
a 6xx response then the SCC AS shall consider the Inter-UE Transfer operation failed and shall send the SIP NOTIFY 
request to controller UE with the body populated with SIP/2.0 603 Declined. 
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1 8 Roles for release of collaborative session for inter-UE 
transfer 

18.1 Introduction 

This clause specifies the roles of controller UE, controllee UE and the SCC AS when controller UE or the remote UE 
releases the collaborative session. 

18.2 SCUE 

1 8.2. 1 Procedures for collaborative session release by controller UE 

18.2.1.1 Controller UE 

There are no specific procedures for the controller UE for the collaborative session release besides the procedures 
described in 3GPP TS 24.229 [2] . 

18.2.1.2 Controllee UE 

There are no specific procedures for the controllee UE for the collaborative session release besides the procedures 
described in 3GPP TS 24.229 [2] . 

1 8.2.2 Procedures for collaborative session release by remote party 

18.2.2.1 Controller UE 

There are no specific procedures for the controller UE for the collaborative session release besides the procedures 
described in 3GPP TS 24.229 [2]. 

18.2.2.2 Controllee UE 

There are no specific procedures for the controllee UE for the collaborative session release besides the procedures 
described in 3GPP TS 24.229 [2] . 

18.3 SCC AS 

1 8.3. 1 Procedures for collaborative session release by controller UE 

When the SCC AS receives a SIP BYE request from the controller UE for releasing a collaborative session, the SCC AS 
shall send a SIP BYE request according to the procedures described in 3GPP TS 24.229 [2] to the remote UE and to all 
controllee UEs within that collaborative session. 

1 8.3.2 Procedures for collaborative session release by remote party 

When the SCC AS receives a SIP BYE request from the remote party for releasing a collaborative session, the SCC AS 
shall send a SIP BYE request according to the procedures described in 3GPP TS 24.229 [2] to the controller UE and to 
all controllee UEs within that collaborative session. 
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1 9 Roles for media adding/deleting within collaborative 
session for inter-UE transfer 

19.1 Introduction 

This clause specifies the roles of the controller UE, the controllee UE and the SCC AS when the controller UE or the 
remote UE adds or releases media to the collaborative session. 

19.2 SCUE 

1 9.2.1 Procedures for adding new media on controllee UE by controller UE 

The SC UE procedures for adding new media to a controllee UE by the controller UE is the same as the procedure 
described in subclause 16.2.2.1 with exception that the controller UE additionally sets the port numbers for the media 
types of the media components (in the "body" URI header field of the SIP URI in the Refer-To header field of the SIP 
REFER request) which are being added to the controllee UE to values from the corresponding media lines received 
during the last successful SDP offer and answer exchange with the remoteparty. 

1 9.2.2 Procedures for releasing media on controllee UE by controller UE 

The controller UE may release one or more media components on a controllee UE within a collaborative session while 
it has an ongoing IMS session with a remote UE. 

The controller UE shall release the media by sending a SIP REFER request for releasing media component, including: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header field as follows: 

a) the SIP URI of the controllee UE; 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) lines in the session shall be set as follows: 

- media lines that are not being released with their port numbers; and 

- media line(s) that are to be released with the port number set to zero; 

3) the Accept header field set to "message/sipfrag"; 

4) the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of 
the dialog between the SCC AS and the controller UE; 

5) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex C; and 

6) the Referred-By header field containing a currently registered public user identity of the user to be delivered to 
the controllee UE. 

The controller UE shall handle SIP response to the SIP REFER request and the subsequent SIP NOTIFY requests 
according to 3GPP TS 24.229 [2]. The controller UE shall save the media information (e.g. media line number) 
received in the sipfrag body of the SIP NOTIFY request in order to perform further inter-UE transfer operations on the 
controllee UE. 
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19.2.2A Procedures for releasing media on controller UE by controller UE 

If the controller UE wants to release a media component on the controller UE within a collaborative session, the 
controller UE shall follow the procedures defined in 3GPP TS 24.229 [2] for removing media with the following 
differences: 

1 . include the SDP information for all other media components within the collaborative session in the SIP re- 
INVITE request; 

2. set all the port numbers of the media on the controllee UEs with value zero; and 

3. include the g.3gpp.iut-controller media feature tag as described in annex C in the Contact header field. 

1 9.2.2B Procedures for controller UE to remove a controllee UE from the 
collaborative session 

The controller UE may remove a controllee UE from a collaborative session while it has an ongoing IMS session with a 
remote UE. 

The controller UE shall remove the controllee UE from the collaborative session by sending a SIP REFER request, 
including: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header as follows: 

a) the SIP URI of the controllee UE; 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the method parameter set equal to "BYE"; 

3) the Accept header field set to include "message/sipfrag"; 

4) the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of 
the dialog between the SCC AS and the controller UE; and 

5) the Referred-By header field containing a currently registered public user identity of the user to be delivered to 
the controllee UE; and 

6) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex C. 

The controller UE shall handle response to the SIP REFER request and the subsequent SIP NOTIFY requests according 
to 3GPP TS 24.229 [2]. 

1 9.2.3 Procedures for releasing media component by controllee UE 
19.2.3.1 Controller UE 

When controller UE receives a SIP re-INVITE request, it can contain an SDP offer with: 

- media lines for media components already terminated at the controller UE with non-zero port numbers; 

- media line(s) for media components terminated at the controllee UE which is releasing the media conponent(s) 
with non-zero port number(s); and 

- media lines for media components terminated at other controllee UEs, with port numbers set to zero. 

Upon receiving such a SIP re-INVITE request, the controller UE shall follow the procedures described in 
3GPP TS 24.229 [2] to accept or reject the released media component(s) by the controllee UE. 
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If the released media component(s) is the only media component(s) used within the collaborative session and the 
controller UE did not accept that media component, the controller UE shall release the collaborative session following 
the procedures described in 3GPP TS 24.229 [2]. 

19.2.3.2 ControlleeUE 

There are no specific procedures for the controllee UE for release of media component by controllee UE, besides the 
procedures described in 3GPP TS 24.229 [2]. 

1 9.2.4 Procedures for modifying media on controllee UE by itself 

If the controllee UE wants to modify the characteristics of a media component on itself within a collaborative session, 
the controllee UE shall follow the procedures defined in 3GPP TS 24.229 [2] for modifying media. 

1 9.2.5 Procedures for adding new media by remote UE when the controller 
UE does not alert the user 

When controller UE receives a SIP re-INVITE request within an existing dialog from the remote UE to add a new 
media component on the collaborative session, the controller UE shall decide whether adding the new media on itself or 
adding it to one of its controllee UE. 

If the controller UE decides to add the new media component on itself, the controller UE shall follow the precedure as 
specified in 3GPP TS 24.229 [2], 

If the controller UE decides to add the new media component on one of its controllee UE, the controller UE shall send a 
SIP REFER request outside the existing dialog as specified in IETF RFC 3515 [13] and include: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI;; 

2) the Refer-To header field, including: 

a) the SIP URI of the controllee UE where the media stream should be established from; and 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) lines in the session shall be set as follows: 

- media lines that are not being transferred with the port number set to zero; 

media line(s) that are to be added at the controllee UE the same SDP information as in the SIP re-INVITE 
request received from the remote UE. 

3) the Accept header field containing the MIME types "message/sipfrag"; 

4) the Target-Dialog header field containing the dialog parameters for the dialog of the existing session; 

5) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex C; and 

6) the Referred-By header field containing a currently registered public user identity of the user to be delivered to 
the controllee UE. 

The controller UE shall handle a SIP response to the SIP REFER request and the subsequent SIP NOTIFY requests 
according to 3GPP TS 24.229 [2]. Then the controller UE shall respond to the SIP re-INVITE request with a SIP 200 
(OK) response with a SDP answer as specified in 3GPP TS 24.229[2] including in the Contact header field the 
g.3gpp.iut-controller media feature tag as described in annex C, and construct the SDP information in the SIP 200 (OK) 
response as follows: 

1) set the port number of the new added media component with value zero; and 

2) set all the ports number of the media on the controllee UEs with value zero; and 

3) for other media components on the controller UE are not changed. 
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If an error response is received for the SIP REFER request or the subsequent SIP NOTIFY requests include a non-2xx 
final response, the controller UE shall consider the transfer operation failed and make a decision again whether adding 
the new media on itself or adding it on other controllee UE. 

1 9.2.6 Procedures for releasing media by remote UE 

Upon receipt of a SIP re-INVITE request from the remote party containing an SDP offer indicating one or more media 
components are to be released on the controller UE, the controller UE shall release the media component following the 
procedures specified in 3GPP TS 24.229 [2]. 

If the media component to be released is the last media component between the controller UE and the remote party and 
if there are more media components within the collaborative session, the controller UE shall not release the dialog with 
the SCC AS but set the port number(s) associated to the media type(s) to zero. 

If the media component to be released is the last media component in the collaborative session, the controller UE shall 
follow the procedures described in subclause 18.2.1.1. 

19.3 SCC AS 

1 9.3.0 Distinction of requests at the SCC AS 

When SCC AS receives a SIP REFER request within a new dialog from the controller UE with: 

1) the Request-URI set to inter UE transfer SCC AS URI; 

2) the Target-Dialog header field identifies an existing dialog between the SCC AS and the controller UE; and 

3) the Refer-To header field set to SIP URI of a controllee UE and containing the URI header field with the hname 
"body" containing SDP with a media type for each of the media (m=) lines in the session as follows: 

all the media components with associated information in the session; and 

- one or more new media components which are not used in the collaborative session yet and with associated 
port number set to the discard port number "9"; 

the SCC AS shall follow the procedure in subclause 19.3.1 to add the media component to the controllee UE. 

When the SCC AS receives a SIP REFER request in a new dialog from the controller UE with: 

1) the Request-URI set to inter UE transfer SCC AS URI; and 

2) the Target-Dialog header field identifies an existing dialog between the SCC AS and the controller UE; 

3) the Refer-To header field containing the SIP URI of a controllee UE and containing the URI header field with 
the hname a "body" containing SDP with a media type for each of the media (m=) lines in the session as follows 

- all the media components with associated information in the session; and 

- the media component which is currently used in the collaborative session by the controllee UE is listed with 
port number set to 0. 

then the SCC AS shall follow the procedure in subclause 19.3.2 to release the media component from the controllee UE. 
When the SCC AS receives a SIP REFER request in a new dialog from the contoller UE with: 

1) the Request-URI set to SIP URI of the SCC AS; 

2) the Target-Dialog header field identifies and existing dialog between the SCC AS and the controller UE; and 

3) the Refer-To header field containing the SIP URI of a controllee UE and the method parameter set equal to 
"BYE"; 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 



69 



ETSI TS 124 237 V9.4.0 (2010-10) 



then the SCC AS shall follow the procedure in subclause 19.3.2B to remove the controllee UE.from the collaborative 
session. 

1 9.3.1 Procedures for adding new media on controllee UE by controller UE 

The SCC AS procedures for adding new media on controllee UE by the controller UE is the same as the procedure 
described in subclause 16.3.3 with exception that upon receipt of SIP REFER request from the controller UE, the SCC 
AS generates a SIP re-INVITE request within the dialog to the controllee UE instead of SIP INVITE request. 

1 9.3.2 Procedures for releasing media on controllee UE by controller UE 

When SCC AS receives a SIP REFER request in a new dialog from the controller UE containing a Refer-To header 
indicating that a SIP INVITE request is to be sent to remove one or more media components on a controllee UE, the 
SCC AS shall send: 

1) a SIP 202 (Accepted) response to the controller UE; 

2) SIP NOTIFY request with a sipfrag including SIP 100 (Trying) to the controller UE; 

3) send a SIP UPDATE request or a SIP re-INVITE request towards the remote leg as specified in 
3GPP TS 24.229 [2] with the following clarifications: 

- if the controllee UE is sending media, include a "a=sendonly" attribute for the media component to be 
released; 

- if the controllee UE is only receiving media, include a "a=inactive" attribute for the media component to be 
released; 

- include b=RR:0 and b=RS:0 bandwidth modifiers as specified in IETF RFC 3556 [50] for the media 
component to be released; and 

When the SIP 200 (OK) response to the SIP UPDATE request or the SIP re-INVITE request is received from the 
remote leg the SCC AS continues with the next steps; 

NOTE 1: The steps in 3) are needed to avoid unnecessary ICMP message sending in the underlying IP network due 
to media sent to closed port that could result in the release of the call. The ICMP message is specified in 
IETF RFC 792 [51]. 

1) send a SIP re- INVITE request to the controllee UE, containing an SDP offer changed using the media type(s) 
present in the hname "body" URI header field from the SIP URI in the Refer-To header; and 

2) the Referred-By header field containing the values from the Referred-By header field of the received SIP 
REFER request according to the procedures of RFC 3892 [59]. 

NOTE 2: This SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 

was generated by the SCC AS due to third party call control to allow sending this SIP re-INVITE request. 

Upon receiving a SIP 200 (OK) response from the controllee UE, the SCC AC shall send a SIP re-INVITE request to 
the remote leg as specified in 3GPP TS 24.229 [2]. The SCC AS shall construct the SDP information in the SIP re- 
INVITE request as follows: 

1) set port number for each removed media component to zero; and 

2) include the SDP information for all other media components in the collaborative session as from the original 
session to the remote leg. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote leg, the SCC AS shall send: 

1) a SIP ACK request to the remote leg; 

2) upon successful release of the media component, a SIP NOTIFY request to the controller UE containing a 
sipfrag body that shall include the SIP 200 (OK) response of the SIP re-INVITE request and also include the 
Content-Type header field from the received 200 (OK) response along with the SDP answer received from the 
controllee UE. 
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19.3.2A Procedures for releasing media on controller UE by controller UE 

When SCC AS receives a SIP re-INVITE request within an existing dialog from the controller UE to remove a media 

component on itself, the SCC AS shall send a SIP re-INVITE request to the remote UE as specified in 

3GPP TS 24.229 [2]. The SCC AS shall construct the SDP information in the SIP re-INVITE request as follows: 

1) set port number(s) for each of the removed media component(s) to zero; and 

2) include the SDP information for all other media components in the collaborative session as received during the 
last successful SDP offer-answer exchange from the remote UE. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote UE, the SCC AS shall send: 

1) a SIP ACK request to the remote UE; 

2) a SIP 200 (OK) response to the controller UE as specified in 3GPP TS 24.229 [2]. The SCC AS shall construct 
the SDP infromation in the SIP 200 (OK) response as follows: 

- set port number(s) for each of the removed media component(s) to zero; and 

- set all the ports number of the media on the controllee UEs with value zero. 



19.3.2B Procedures for controller UE removing controllee UE from the 
collaborative session 

When SCC AS receives a SIP REFER request in a new dialog from the controller UE containing a Refer-To header 
indicating that a SIP BYE request is to be sent to a controllee UE, the SCC AS shall send: 

1) SIP 202 (Accepted) response to the controller UE; 

2) SIP NOTIFY request with sipfrag including SIP 100 Trying to the controller UE; and 

3) SIP UPDATE request or a SIP re-INVITE request towards the remote leg as specified in 3GPP TS 24.229 [2] 
with the following clarifications: 

- if the controllee UE is sending media, include a "a=sendonly" attribute for the media component to be 
released; 

- if the controllee UE is only receiving media, include a "a=inactive" attribute for the media component to be 
released; and 

include b=RR:0 and b=RS:0 bandwidth modifiers as specified in IETF RFC 3556 [50] for the media 
component to be released. 

NOTE: The steps in 3) are needed to avoid unnecessary ICMP message sending in the underlying IP network due 
to media sent to closed port that could result in the release of the call. The ICMP message is specified in 
IETF RFC 792 [51]. 

When the SIP 200 (OK) response to the SIP UPDATE request or the SIP re-INVITE request is received from the 
remote leg the SCC AS shall send a SIP BYE request to the controllee UE to release the controlled session in 
accordance with 3GPP TS 24.229 [2] including the Referred-By header field containing the values from the Referred- 
By header field of the received SIP REFER request according to the procedures of RFC 3892 [59]. 

Upon receiving SIP 200 (OK) response from the controllee UE, the SCC AC shall send a SIP re-INVITE request to the 
remote leg as specified in 3GPP TS 24.229 [2]. The SCC AS shall construct the SDP information in the SIP re-INVITE 
request as follows: 

1) set port number(s) for each removed media component(s) to zero; and 

2) include the SDP information for all other media components in the collaborative session as from the original 
session to the remote leg. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote leg, the SCC AS shall send: 
1) a SIP ACK request to the remote leg; 
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2) upon successful release of the media component, a SIP NOTIFY request to the controller UE containing a 
sipfrag body that shall include the SIP 200 (OK) response of the SIP BYE request. 



1 9.3.3 Procedures for releasing media component initiated by controllee 
UE 

When the SCC AS receives a SIP re-INVITE request from a controllee UE containing an SDP offer with one or more 
media line(s) used on the controllee UE with port number set to zero, where the port number was previously not zero, 
the SCC AS shall send a SIP re-INVITE request towards the controller UE containing an SDP offer with the following 
details: 

1) for the media lines on the controller UE, set the port numbers to the values received during the last successful 
SDP offer and answer exchange with the remote party; 

2) for the media lines on the controllee UE which were offered with port numbers set to zero in the SDP offer 
received in the re-INVITE from the controllee UE, set the port numbers to the values received during the last 
successful SDP offer and answer exchange with the remote party; and 

3) set the port number to zero for the remaining media lines. 

When the SCC AS receives a SIP BYE request from a controllee UE, the SCC AS shall send a SIP re-INVITE request 
towards the controller UE containing an SDP offer with the following details: 

1) for the media lines on the controller UE, set the port numbers to the values received during the last successful 
SDP offer and answer exchange with the remote party; 

2) for the media lines on the controllee UE, set the port numbers to the values received during the last successful 
SDP offer and answer exchange with the remote party; and 

3) set the port number to zero for the remaining media lines. 

Upon receiving the SIP 200 (OK) response to the SIP re-INVITE request from the controller UE and in addition to the 
procedures of 3GPP TS 24.229 [2], the SCC AS shall send a SIP re-INVITE request towards the remote party 
containing an SDP offer with: 

1) all the media lines which were not released by the controllee UE including their port numbers; and 

2) all the media lines which were released by the controllee UE set to the port numbers received in the SDP answer 
contained in the SIP 200 (OK) response from the controller UE. 

Upon receiving the SIP 200 (OK) response from the remote party, and in additon to the procedures of 
3GPP TS 24.229 [2], the SCC AS shall: 

1) if the transaction was initiated by a SIP re-INVITE request, send a SIP 200 (OK) response for the SIP re- 
INVITE request towards the controllee UE containing an SDP answer accepting the SDP offer from the 
controllee UE; or 

2) if the transaction was initiated by a SIP BYE request, send a SIP 200 (OK) response for the SIP BYE request 
towards the controllee UE. 



1 9.3.4 Procedures for modifying media on controllee UE by itself 

When SCC AS receives a SIP re-INVITE request within an existing dialog from the controllee UE to modify a media 

component on itself, the SCC AS shall send a SIP re-INVITE request to the remote UE as specified in 

3GPP TS 24.229 [2]. The SCC AS shall construct the SDP information in the SIP re-INVITE request as follows: 

1) set the modified media information as the same in the SIP re-INVITE request received from the controllee UE; 
and 

2) include the SDP information for all other media components in the collaborative session as received during the 
last successful SDP offer-answer exchange from the remote UE. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote UE, the SCC AS shall send: 
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1) a SIP ACK request to the remote UE; and 

2) a SIP 200 (OK) response to the controllee UE with an SDP answer that only contains the media component on 
the controllee UE. 

1 9.3.5 Procedures for adding new media by remote UE when the controller 
UE does not alert the user 

When SCC AS receives a SIP REFER request from the controller UE to add a new media component on a controllee 
UE, the SCC AS shall send: 

1) SIP 202 (Accepted) response 

2) SIP NOTIFY request containing a sipfig for a SIP 100 (Trying) response to the controller UE as described in 
IETF RFC 3515 [13]; 

3) if the target controllee UE has not been involved in the collaborative session, send a initial SIP INVITE request 
to the controllee UE to add the controlee UE in the collaborative session, containing: 

a) Request-URI with SIP URI from the Refer-To header field of the received SIP REFER request; 

b) the Referred-By header field containing the values from the Referred-By header field of the received SIP 
REFER request according to the procedures of RFC 3892 [59]; 

c) the P-Asserted-Identity header field containing the identity of the remote UE as received in the P-Asserted- 
Identity header field from SIP re-INVITE request received from the remote UE; and 

d) the SDP information for the media component to be transferred as follows: 

- The media type(s) from the media (m=) lines from the hname "body" URI header field from the SIP URI 
in the Refer-To header field of the received SIP REFER request; and 

for media lines which have non zero port numbers the SDP parameters from the corresponding media 
lines as received in the SDP offer from the remote UE in the SIP re-INVITE request. 

4) if there are other media component within the collaborative session between the target controllee UE and the 
remote UE, send a SIP re-INVITE request to the controllee UE, containing: 

a) the Referred-By header field containing the values from the Referred-By header field of the received SIP 
REFER request according to the procedures of RFC 3892 [59]; 

b) the SDP information for the media component to be transferred as follows: 

The media type(s) from the media (m=) lines from the hname "body" URI header field from the SIP URI 
in the Refer-To header field of the received SIP REFER request; and 

- for media lines which have non zero port numbers, the SDP parameters from the corresponding media 
lines as received in the SDP offer from the remote UE in the SIP re-INVITE request 

for other media components that have already involved in the collabartive session are not changed. 

Upon receiving a SIP final response from the controllee UE, the SCC AS shall send, a SIP NOTIFY request containing 
the received response code in the sipfrag body and if the received SIP response was a SIP 200 (OK) response containing 
an SDP answer then also include in the sipfrag the Content-Type header field from the received SIP 200 (OK) response 
along with the media (m=) lines from the SDP answer. 

If the SIP final response was a non 2xx response then the SCC AS shall consider the transfer operation failed and abort 
the media transfer. 

If the SIP final response was a SIP 200 (OK) response containing a SDP answer, the SCC AS shall: 

1) send a SIP ACK request to the controllee UE; 

2) send a SIP 200 (OK) response to the remote UE as specified in 3GPP TS 24.229 [2]. The SCC AS shall 
construct the SDP infromation in the SIP 200 (OK) response as follows: 
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set the same SDP information for the new added media as in the SIP 200 (OK) response received from the 
controlee UE; and 

- include the SDP information for all other media in the collaborative session as received during the last 
successful SDP offer-answer exchange from the remote UE. 

1 9.3.6 Procedures for releasing media by remote UE 

Upon receipt of a SIP re -INVITE request from the remote party containing an SDP offer indicating one or more media 
components to be released on the controller UE, the SCC AS shall set the port number on the media line(s) which are 
not on controller UE to zero and forward the SIP re-INVITE request towards the controller UE following the 
procedures as specified in 3GPP TS 24.229 [2]. 

Upon receipt from the remote party of a SIP re-INVITE request containing an SDP offer indicating one or more media 
components to be released on the controllee UE, the SCC AS shall: 

if there are more media components left after releasing the selected media components, set the port number(s) on 
the media line(s) which are not on the controllee UE to zero and forward the SIP re-INVITE request; or 

- if there are no more media components left after releasing the selected media components, send a SIP BYE 
request; 

towards the controllee UE following the procedures as specified in 3GPP TS 24.229 [2]. 

Upon receipt of a SIP re-INVITE request from the remote party containing an SDP offer indicating one or more media 
components to be released on the controller UE and one or more media components to be released on the controllee 
UE(s), the SCC AS shall: 

send a SIP re-INVITE request to the controller UE containing the SDP received from the remote end with the 
exception that the port numbers of the media components, not terminated on the controller UE, are set to zero; 

if not all the media component(s) are being released on the controllee UE, send a SIP re-INVITE request to that 
controllee UE, containing the SDP received from the remote end with the exception that the port numbers of the 
media components, not terminated on the controllee UE, are set to zero; and 

- if all the media component(s) are being released on the controllee UE, send a SIP BYE request to the controllee 
UE. 



20 Service continuity and MMTEL interactions 

20.1 Roles for access tranfer and supplementary services 
interaction 

20.1.1 Introduction 

This subclause describes the SCC AS and SC UE procedures for interaction of access transfer when execution of 
supplementary service as described in 3GPP TS 22.173 [24]. 

20.1.2 Originating Identification Presentation (OIP) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and OIP besides the 
procedures described in 3GPP TS 24.607 [25]. 

20.1.3 Originating Identification Restriction (OIR) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and OIR besides the 
procedures described in 3GPP TS 24.607 [25]. 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 



74 



ETSI TS 124 237 V9.4.0 (2010-10) 



20.1.4 Terminating Identification Presentation (TIP) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and TIP besides the 
procedures described in 3GPP TS 24.608 [26]. 

20.1.5 Terminating Identification Restriction (TIR) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and TIP besides the 
procedures described in 3GPP TS 24.608 [26]. 

20.1.6 Communication Diversion (CDIV) 

Upon receiving an incoming session split across multiple access legs, if the SC UE desires to invoke the CDIV, it may 
choose any of the PS access legs to invoke the call deflection supplementary service following the procedures described 
in 3GPP TS 24.604 [27] or the CS access leg to invoke the call deflection supplementary service following the 
procedures described in 3GPP TS 24.072 [42]. 

NOTE: Communication Forwarding unconditional, Communication forwarding on no reply, Communication 
Forwarding on Busy, Communication Forwarding Not Logged-in and Communication Diversion 
Notification supplementary services are invoked by the CDIV AS as described in 3GPP TS 24.604 [27] 
independent on access type. 

When the SCC AS which is dividing an IMS session into multiple access legs, receives a CDIV request from the SC UE 
on any access leg, the SCC AS shall terminate any other access legs and invoke the CDIV for that access leg according 
to the procedures described in 3GPP TS 24.604 [27]. 

20.1 .7 Communication Hold (HOLD) 

When the SC UE which is dividing an IMS session through multiple access legs, desires to invoke HOLD on one or 
more media componets, it shall proceed according to the procedures described in 3GPP TS 24.610 [28] for PS access 
legs, 3GPP TS 24.083 [43] for a CS access leg not controlled by the II interface or 3GPP TS 24.294 [44] for a CS 
access leg controlled by the II interface which contains the affected media components. 

When the SCC AS which dividing an IMS session into multiple access legs, receives a HOLD request from the SC UE 
or remote end on any access leg, it shall proceed according to the procedures described in 3GPP TS 24.610 [28] for that 
access leg. 

20.1.8 Communication Barring (CB) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CB besides the 
procedures described in 3GPP TS 24.61 1 [29]. 

20.1 .9 Message Waiting Indication (MWI) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and MWI besides the 
procedures described in 3GPP TS 24.606 [30]. 

20.1.10 Conference (CONF) 

When the SC UE has multiple access legs and if it wants to send any CONF related requests such as SIP SUBSCRIBE 
request or SIP REFER request, the SC UE may send the request on the PS access leg as describes in 
3GPP TS 24.605 [31] or use the procedures described in 3GPP TS 24.294 [44] for a CS access leg controlled by the II 
interface. For a CS access leg without II interface control the procedures in 3GPP TS 24.084 [47] shall be used to create 
and add participants to a conference. 

When the SC UE has multiple access legs and if it receives a request on one of the access legs for CONF service to 
replace an existing session, the SC UE shall: 

- if each access les is PS access leg, follow procedures specified in 3GPP TS 24.605 [31] to establish a new 
session to the conference focus; 
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if the CS access leg is not controlled by the II interface follow the procedures in 3GPP TS 24.008 [8] for 
releasing and establishing a new call towards the conference focus; and 

- if the CS access leg is controlled by the II interface follow the procedures in 3GPP TS 24.294 [44] for establish 
a new session towards the conference focus. 

When the SC UE has multiple access legs and if it receives a request on one the access legs for CONF service to replace 
an existing session outside the dialog, the SC UE shall follow procedures specified in 3GPP TS 24.605 [31] to establish 
a new session to the conference focus. 

When the SC UE has multiple access legs and if the remote UE sends a request for the CONF servive to replace an 
existing session within the same dialog, the SCC AS shall deliver the request for CONF service on the Gm controlled 
any of access legs or over the II interface if II interface control is used or to the CS leg if only a CS leg exists, to the SC 
UE. 

20.1 .1 1 Explicit Communication Transfer (ECT) 

When the SC UE has multiple access legs and if it acts as the transferor UE, the SC UE may send the request for ECT 
service on any of the PS legs as specified in 3GPP TS 24.629 [32], or on the CS access leg not controlled by the II 
interface follow the procedures in 3GPP TS 24.091 [46] and on a CS access leg controlled by the II interface follow the 
procedures in 3GPP TS 24.294 [44]. 

When the SC UE has multiple access legs and if it acts as the transferee UE, the SCC AS may deliver the request for 
ECT service on any of the access legs. 

NOTE: Delivering of the request towards the CS access leg may be controlled by operator policy. 

When the SC UE has multiple access legs and if it receives an ECT request on one of the access legs, the SC UE shall 
follow the procedures specified in 3GPP TS 24.629 [32] to establish a new session to the Transfer Target. 

20. 1 . 1 2 Advice of Charge (AOC) 

When the AOC service as specified in 3GPP TS 24.647 [33] is active and if the SC UE has multiple access legs, the 
SCC AS may deliver charging information during the communication to the SC UE over any of the access legs which 
accept application/vnd.etsi.aoc+xml MIME type. 

20.1.13 Closed User Groups (CUG) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CUG besides the 
procedures described in 3GPP TS 24.654 [34]. 

20.1.14 Three-Party (3PTY) 

The 3PTY service is considered as a special case of CONF service in 3GPP TS 24.605 [31] and the interaction with 
session transfer is the same as that specified in subclause 20.1.10 for CONF service. 

20.1.15 Flexible Alerting (FA) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and FA besides the 
procedures described in 3GPP TS 24.239 [35]. 

20.1 .1 6 Communication Waiting (CW) 

Upon receiving an incoming session split across multiple access legs if the SC UE desires to invoke the CW, it may 
choose any of the access legs to invoke the CW service following to the procedures defined in 3GPP TS 24.615 [36]. 

When the SCC AS which is dividing an IMS session into multiple access legs, receives a CW request from the SC UE 
on any access leg, the SCC AS shall invoke the CW service following the procedures defined in 3GPP TS 24.615 [36]. 
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20.1 .1 7 Completion of Communications to Busy Subscriber 
(CCBS)/Completion of Communications by No Reply (CCNR) 

There are no specific procedures for the SC UE and the SCC AS for interaction of access transfer and CCBS/CCNR 
besides the procedures described in 3GPP TS 24.642 [37]. 

20. 1 . 1 8 Customized Alerting Tones (CAT) 

There are no specific procedures for the SC UE and the SCC AS for CAT besides the procedures described in 
3GPPTS 24.182 [38]. 

20.1.19 Malicious Communication IDentification (MCID) 

When invoking the MCID service in temporary subscription mode and there are multiple active access legs for the 
session, the SC UE may send the SIP re-INVITE request for invoking MCID service as defined in 3GPP TS 24.616 [39] 
on any of the access legs. 

20.1.20 Reverse Charging 

The interaction of the Reverse Charging service according to 3GPP TS 24.647 [33] with access transfer is not specified 
in this version of the specification. 

20.1 .21 Personal Network Management (PNM) 

The interaction of the PNM service according to 3GPP TS 24.259 [40] with access transfer is not specified in this 
version of the specification. 

20.1.22 Customized Ringing Signal (CRS) 

The interaction of the CRS service according to 3GPP TS 24.183 [41] with access transfer is not specified in this 
version of the specification. 

20.2 Roles for inter-UE transfer and supplementary services 
interaction 

20.2.1 Introduction 

This subclause describes the SCC AS and SC UE procedures for inter-UE transfer when execution of supplementary 
service as described in 3GPP TS 22.173 [24]. 

20.2.2 Originating Identification Presentation (OIP) 

There are no specific procedures for the SC UE and the SCC AS for OIP besides the procedures described in 
3GPP TS 24.607 [25]. 

20.2.3 Originating Identification Restriction (OIR) 

There are no specific procedures for the SC UE and the SCC AS for OIR besides the procedures described in 
3GPP TS 24.607 [25]. 

20.2.4 Terminating Identification Presentation (TIP) 

There are no specific procedures for the SC UE and the SCC AS for TIP besides the procedures described in 
3GPPTS 24.608 [26]. 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 



77 



ETSI TS 124 237 V9.4.0 (2010-10) 



20.2.5 Terminating Identification Restriction (TIR) 

There are no specific procedures for the SC UE and the SCC AS for TIP besides the procedures described in 
3GPPTS 24.608 [26]. 

20.2.6 Communication Diversion (CDIV) 

There are no specific procedures for the SC UE and the SCC AS for TIP besides the procedures described in 
3GPPTS 24.604 [27]. 

20.2.7 Communication Hold (HOLD) 

The controller UE may hold an active media component(s) on itself, by following the procedures for HOLD described 
in 3GPPTS 24.610 [28]. 

The controller UE may hold or resume an active media component(s) on a controllee UE within a collaborative session 
while it has an ongoing IMS session with a remote UE, by sending a SIP REFER request and including: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Refer-To header as follows: 

a) the SIP URI of the controllee UE; 

NOTE: The SIP URI of the controllee UE needs to be a GRUU if the controllee UE and any other UEs share the 
same public user identity. 

b) the SIP URI additionally containing the URI header field with the hname "body" containing SDP for the 
media type for each of the media (m=) lines in the session shall be set as follows: 

- media lines for those media components that are not terminated on the controllee UE with port number 
zero; 

- media lines for those media components that are terminated on the controllee UE and are not to be 
changed with their current directionality and the current port number from the remote end; and 

- media lines for those media components that are terminated on the controllee UE and: 

- if those media components are to be held, set a-line to inactive or recvonly and the current port 
number from the remote end; or 

- if those media components are to be resumed, set a-line to sendonly or sendrecv and the current port 
number from the remote end. 

3) the Accept header field set to "message/sipfrag"; and 

4) the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of 
the collaborative session; and 

5) the Contact header field containing the g.3gpp.iut-controller media feature tag as described in annex C. 

The controller UE shall handle response to the SIP REFER request and the subsequent SIP NOTIFY requests according 
to 3GPP TS 24.229 [2]. 

When SCC AS receives a SIP REFER request from the controller UE to hold or resume a media component on a 
controllee UE, the SCC AS shall send: 

1) a SIP 202 (Accepted) response for the SIP REFER request to the controller UE; 

2) a SIP NOTIFY request with sipfrag including SIP 100 Trying to the controller UE; and 

3) send a SIP re- INVITE request to the controllee UE, containing: 

a) the Referred-By header field containing the values from the Referred-By header field of the received SIP 
REFER request according to the procedures of RFC 3892[59]; and 
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b) an SDP offer as received from remote UE in the previous offer/answer exchanged and with directionality as 
set for the corresponding media types in the hname "body" URI header field from the SIP URI in the Refer- 
To header field of the SIP REFER request received from the controller. 

Upon receiving SIP 200 (OK) response from the controllee UE, the SCC AC shall send: 

1) a SIP NOTIFY request to the controller UE with the sipfrag body including the SIP 200 (OK) response of the 
SIP re-INVITE request and also include the SDP information received from the controllee UE. 

2) a SIP re-INVITE request to the remote leg as specified in 3 GPP TS 24.229 [2]. The SCC AS shall construct the 
SDP information in the SIP re-INVITE request as follows: 

set the SDP information including the directionality as received in the SIP 200 (OK) response from the 
controlee UE; and 

- include the SDP information for all other media components in the collaborative session as from the original 
session to the remote leg. 

Upon receiving SIP 200 (OK) response with the SDP answer from the remote leg, the SCC AS shall send a SIP ACK 
request to the remote leg; 

When a controllee UE receives a SIP re-INVITE request to hold a media component(s), it shall follow the procedures 
described in 3GPP TS 24.610 [28]. 

20.2.8 Communication Barring (CB) 

There are no specific procedures for the SC UE and the SCC AS for CB besides the procedures described in 
3GPPTS 24.611 [29]. 

20.2.9 Message Waiting Indication (MWI) 

There are no specific procedures for the SC UE and the SCC AS for MWI besides the procedures described in 
3GPPTS 24.606 [30]. 

20.2.10 Conference (CONF) 

In a collaborative session, it shall only be possible for the controller UE to invoke the CONF service following the 
procedures as described in 3GPP TS 24.605 [31]. 

When the remote UE sends a request for the CONF service to replace an existing collaborative session, the SCC AS 
shall deliver the request for CONF service to the controller UE, which then sets up new session following the 
procedures described in 3GPP TS 24.605 [31]. 

20.2.1 1 Explicit Communication Transfer (ECT) 

In a collaborative session, it shall only be possible for the controller UE to invoke ECT service following the procedures 
as described in 3GPP TS 24.629 [32]. 

When the controller UE receives a notification that ECT has been performed successfully, the controller UE shall 
terminate the previous active session with the transferee UE by terminating all related media control sessions on the 
controllee UEs. 

When the SCC AS receives an ECT transfer request from the remote end to transfer the collaborative session, the SCC 
AS shall deliver the request to the controller UE. 

When the controller UE receives an ECT transfer request to transfer the collaborative session, the controller UE shall 
establish a new session towards the transfer target following the procedures described in 3GPP TS 24.629 [32]. 

20.2.12 Advice of Charge (AOC) 

When the AOC service specified in 3GPP TS 24.647 [33] is active, the SCC AS shall deliver charging information to 
the controller UE. 
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20.2.13 Closed User Groups (CUG) 

There are no specific procedures for the SC UE and the SCC AS for CUG besides the procedures described in 
3GPP TS 24.654 [34]. 



20.2.14 Three-Party (3PTY) 

The 3PTY service is considered as a special case of CONF service in 3GPP TS 24.605 [31] and the interaction with 
inter-UE transfer is the same as that specified in subclause 20.2.10 for CONF service. 

20.2.15 Flexible Alerting (FA) 

There are no specific procedures for the SC UE and the SCC AS for FA besides the procedures described in 
3GPPTS 24.239 [35]. 



20.2.16 Communication Waiting (CW) 

There are no specific procedures for the SC UE and the SCC AS for CW besides the procedures described in 
3GPPTS 24.615 [36]. 

20.2.1 7 Completion of Communications to Busy Subscriber 
(CCBS)/Completion of Communications by No Reply (CCNR) 

There are no specific procedures for the SC UE and the SCC AS for CCBS/CCNR besides the procedures described in 
3GPP TS 24.642 [37]. 



20.2.1 8 Customized Alerting Tones (CAT) 

There are no specific procedures for the SC UE and the SCC AS for CAT besides the procedures described in 
3GPPTS 24.182 [38]. 

20.2.19 Malicious Communication IDentification (MCID) 

There are no specific procedures for the SC UE and the SCC AS for MCID besides the procedures described in 
3GPPTS 24.616 [39]. 



20.2.20 Personal Network Management (PNM) 

There are no specific procedures for the SC UE and the SCC AS for PNM besides the procedures described in 
3GPPTS 24.259 [40]. 

20.2.21 Customized Ringing Signal (CRS) 

There are no specific procedures for the SC UE and the SCC AS for CRS besides the procedures described in 
3GPPTS 24.183 [41]. 
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21 



Roles for session discover 



21.1 



Introduction 



This clause specifies the session discovery procedures of the SC UE and the SCC AS. 



21.2 



SC UE 



21 .2.1 Discovery of collaborative session changes 



In order to get the information about the collaborative session changes, the controller UE shall send SIP SUBSCRIBE 
request according to IETF RFC 4235 [48]. The controller UE shall populate the SIP SUBSCRIBE request as follows: 

1) the Request-URI set to the Inter UE Transfer SCC AS URI; 

2) the Event header field containing the "dialog" event package name and the parameter "include-session- 
description"; 

3) the Target-Dialog header field containing the dialog information of the collaborative session; and 

4) the Expires header field set to: 

a) zero to receive one SIP NOTIFY request; or 

b) different than zero to receive the subsequent SIP NOTIFY requests. 



The SCC AS distinguish between the following initial SIP requests: 
1) SIP SUBSCRIBE request containing: 

a) Request-URI containing the Inter UE Transfer SCC AS SIP URI; and 

b) Target-Dialog header field containing dialog information of a collaborative session belonging to the user 
identified by URI in the P-Asserted-Identity header field. 

In the procedures below, such request is known as "SIP SUBSCRIBE request for discovery of collaborative 
session changes". 

Other SIP SUBSCRIBE requests can be dealt with in any manner conformant with 3GPP TS 24.229 [2]. 

21 .3.2 SCC AS procedures for discovery of collaborative session changes 

When the SCC AS receives a SIP SUBSCRIBE request for discovery of collaborative session changes, the SCC AS 
shall handle the SIP request according to IETF RFC 4235 [48]. 



21.3 



SCC AS 



21.3.1 



Distinction of requests sent to the SCC AS 
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Annex A (informative): 
Example signalling flows 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for Service Continuity based on the Session Initiation Protocol (SIP) and 
SIP Events. 

These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in 
3GPPTS 23.237 [9]. 

A.2 Introduction 
A.2.1 General 

The signalling flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [3]. 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [3] subclauses 4.1 and 4.2 applies with the additions 
specified below: 

- tel:+l-237-555-l 1 1 1 represents the public user indentity of SC UE A. 
tel:+l-237-555-2222 represents the public user indentity of UE B. 
sip:sccasl. homel.net represents the Internet host of SCC AS. 

- sip:interUEtransfer@sccasl. homel.net represents the Inter UE Transfer SCC AS URI of the UA A. 

Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [3]. 

However, 3GPP TS 24.228 [3] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 
3GPP TS 24.228 [3], then such text is not reproduced in the present document. 

Additional text may also be found on the contents of headers within 3GPP TS 24.228 [3] in addition to the material 
shown in the present document. 

In order to differentiate between messages for SIP and media, the notation in figure A.2-1 is used. 

INVITE 

► SIP message 



SETUP 

► CS message 



Media over a PS connection 



Media over a CS connection 



Figure A.2-1 : Signalling flow notation 
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A. 3 Signalling flows for registration 
A.3.1 Introduction 

When using CS access for media and to make use of the ISC procedures, the SC UE is registered in IM CN subsystem 
and the signalling flows are defined in 3GPP TS 24.292 [4] subclause A.2. 

When initiating a CS call, the SC UE can be registered in the CS domain as defined in 3GPP TS 24.008 [8]. 

Whenever the UE acquires IP connectivity via an IP-CAN, the signalling flows for registration in the IM CN subsystem 
are defined in 3GPP TS 24.228 [3]. 



A.3.2 Signalling flows for multiple registration for service 
continuity 

The signalling flows shown in figure A. 3. 2-1 gives an example when a UE connects to different IP-CAN respectively 
and performs multiple registrations. In this example the UE also supports the Controller UE procedures for IUT 
transfer. In this example the SCC AS receives the registration state information that it needs to implement SCC specific 
requirements from the third-party SIP REGISTER request. 



UE 



— 1. SIP Register#l- 



P-CSCF#1 



-6. 200 OK- 



9.UE connects to a 
new IP-CAN 



P-CSCF#2 





I-CSCF 




S-CSCF 




SCC AS 



-2. SIP Register#l- 



-5. 200 OK- 



0. SIP Register#2- 



-15. 401 Unauthorized 

I 

-16. SIP Register#2 ► 



-21.200 OK- 



IE SIP 

~Register#2 



14. 401 
Unauthorized 

17. SIP 

Register#2 



120. 200 OK— 



3. SIP 
Register#l 
-4. 200 OK- 



12. SIP 

Register#2 
13.401 
Unauthorized 



18. SIP 

Register#2 
-19. 200 OK- 



-7. SIP Register 
«-8. 200 OK— 



-22. SIP Register*- 
«-23. 200 OK- 



Figure A.3.2-1 Signalling flows for multiple registrations 

1. SIP REGISTER request (UE to P-CSCF#1)-See example in table A.3.2-1 

UE sends the SIP REGISTER request via the IP-CAN#1. 
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NOTE 1: For clarity, the unprotected SIP REGISTER request via the IP-CAN#1 is not shown in this example. 



Table A.3.2-1SIP REGISTER request (UE to P-CSCF#1) 



REGISTER sipiregistrar.homel.net SIP/2.0 




Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 




Max-Forwards: 70 




P-Access-Network-Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 




From: <sip:userl publiclohomel . net> ; tag=4f a3 




To: <sip:userl publiclohomel . net> 




Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; reg-id=l; +sip . instance= " < 




urn : gsma : imei :90420156-025763-0 >";+g. 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 




service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; +g . 3gpp . access type= " cellularl " ; expires=6000 


; +g . 3gpp . iut -controller 




Call -ID : apb03a0s0 9dkjdfglkj4 9111 




Authorization: Digest username="userl private@homel.net", realm= " registrar . homel . net " 




nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl -MD5 , 




uri=" sip: registrar .homel .net" , response="662 9fae4 93 93a053 9745 097 85 07c4ef 1" 




Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789 ; spi-s=12345678 ; port- 


c=2468 ; 


port-s=1357 




Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c = 98765432 ; spi-s=87654321 ; 


port- 


c=8642; port-s=7531 




Require: sec -agree 




Proxy-Require: sec-agree 




CSeq: 2 REGISTER 




Supported: path, outbound, gruu 




Content-Length: 





2. SIP REGISTER request (P-CSCF#1 to I-CSCF)-See example in table A.3.2-2 

After performing the DNS query, the P-CSCF#1 forwards the SIP REGISTER request towards I-CSCF. The P- 
CSCF adds a Path header field with a flow token and includes the 'ob' parameter 

Table A.3.2-2 SIP REGISTER request (P-CSCF#1 to l-CSCF) 



REGISTER sip : registrar . homel . net SIP/2.0 




Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 




[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 




Max-Forwards: 69 




P-Access-Network-Info : 




Path : <sip : VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf 1 .visitedl . net ; lr ;ob> 




Require: path 




P-Visited-Network- ID : "Visited Network Number 1" 




P -Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " 




From : 




To: 




Contact : 




Call-ID: 




Authorization: Digest username="userl private@homel.net", realm= " registrar . homel . net " , 


nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl -MD5 , 




uri=" sip: registrar .homel .net" , response= " 662 9f ae4 93 93a053 9745 097 85 7c4ef 1 " 


integrity- 


protected= "yes " 




CSeq: 




Supported : 




Content-Length : 





3. SIP REGISTER request (I-CSCF to S-CSCF) 

The I-CSCF forwards the SIP REGISTER request to the S-CSCF. 

4. SIP 200 (OK) response (S-CSCF to I-CSCF)-See example in table A.3.2-4 

The S-CSCF sends a SIP 200 (OK) response to the I-CSCF indicating that Registration was successful. AS the 
URI in the first Path header field has an "ob" URI parameter, it include a Require header field with the option- 
tag "outbound". 
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Table A.3.2-4: SIP 200 (OK) response (S-CSCF to l-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfl_p . homel . net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 
pcscf 1 . visitedl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Path : <sip : termOpcscf 1 .visitedl . net ; lr ;ob> 
Service-Route : <sip : origOscscf 1 . homel . net ; lr> 
From : 
To : 

Call-ID: 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; 

pub-gruu= " sip : userl_publicl@homel .net; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 " 

; temp-gruu= " sip : tgruu . 7hs== j d7vnzga5w7f aj sc7 -aj d6f abzOf 8g5@example . com; gr " 

; +sip . instance= " < urn : gsma : imei :90420156-025763-0 >"+g. 3gpp .icsi-ref = "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; +g . 3gpp . accesstype="cellularl " 

; expires=600000 ; +g . 3gpp . iut-controller 

CSeq: 

Supported: path, outbound 
Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip : userl_public2@homel . net > , <sip : userl_public3@homel . net> , <sip:+l-212- 

555 - llll@homel . net ; user=phone> 
Content-Length : 



5-6. SIP 200 (OK) response (I-CSCF to UE) 

The I-CSCF forwards the SIP 200 (OK) response to the UE via P-CSCF#1. 

7. SIP REGISTER request (S-CSCF to SCC AS)-See example in table A.3.2-7 

After UE successfully registered in the IM CN subsystem, the S-CSCF sends a third party SIP REGISTER 
request to the SCC AS based on the initial filter criteria it received. 

Table A.3.2-7: SIP REGISTER request (S-CSCF to SCC AS) 



REGISTER sip: sccas.homel.net /2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ; branch=z9hG499ffhy 
Max-Forwards: 70 

From: <sip : scscfl . homel . net> ; tag=538ya 
To : <sip : userl_publicl@homel . net > 
Call-ID: lasdaddlrf jflslj40a222 

P-Access-Network-Inf o : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
Contact: <sip : scscfl . homel . net> ; expires=6 
CSeq: 87 REGISTER 

Content - Type : mult ipart /mixed ; boundary= " boundaryl " 
Content-Length: (...) 

- -boundaryl 

Content-Type: message/sip 

REGISTER sip : registrar . homel . net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

P-Access-Network-Inf o : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
Path: <sip : VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf 1 .visitedl . net ; lr ;ob> 
Require: path 

P-Visited-Network- ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value= " AyretyU0dm+6O2IrT5tAFrbHLso=02 3 5 51024 " 
From : <sip : userl_publicl@homel . net > ; tag=4f a3 
To : <sip : userl_publicl@homel . net> 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; reg-id=l; +sip . instance= " < 
urn : gsma : imei :90420156-025763-0>" ;+g. 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ;+g . 3gpp . access type="cellularl ";expires=600000 ; +g . 3gpp . 
iut-controller 

Call -ID: apb0 3a0s0 9dkjdfglkj4 9111 

Authorization: Digest username= "userl_private@homel . net " , realm= " registrar . homel . net " , 

nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 

uri="sip : registrar .homel .net" , response= " 6 62 9f ae4 9393a0 53974 50 97850 7c4ef 1 " 

CSeq: 2 REGISTER 

Supported: path, outbound, gruu 

Content-Length: 
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- -boundaryl 

Content-Type: message/sip 
SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfljp . homel . net ; branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 
pcscfl .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Path : <sip : termOpcscf 1 .visitedl . net ; lr ;ob> 
Service-Route : <sip : origOscscf 1 . homel . net ; lr> 
From : <sip : userl_publicl@homel . net > ; tag=4f a3 
To : <sip : userl_publicl@homel . net> ; tag=3ecl 
Call- ID: apb03a0s09dkjdfglkj 49111 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; 

pub-gruu= " sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 0a0c91e6bf6" 

; temp-gruu= " sip : tgruu . 7hs== j d7vnzga5w7f a j sc7-a j d6f abzOf 8g5@example . com; gr " 

; +sip . instance= " < urn : gsma : imei :90420156-025763-0>";+g. 3gpp . icsi-ref = "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics = "principal "+g . 3gpp . accesstype="cellularl " 

; expires=G00000 ; +g . 3gpp . iut-controller 

Supported: path, outbound 

Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip : userl_public2@homel . net > , <sip : userl_public3@homel . net > , <sip:+l-212-555- 
llllohomel . net ;user=phone> 
CSeq: 2 REGISTER 
Content-Length: 

- -boundaryl- - 



8. SIP 200 OK response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third party SIP REGISTER request. 

9. UE connects to a new IP-CAN 

The UE connects to a new IP -CAN and will perform the registration via the new IP-CAN. 

10. SIP REGISTER request (UE to P-CSCF#2)- See example in table A.3.2-10 

UE sends the unprotected SIP REGISTER request via the new IP-CAN to P-CSCF+2 which in this example is a 
different one with previous registration. 

Table A.3.2-10: SIP REGISTER request (UE to P-CSCF#2) 



REGISTER sip : registrar . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555: : aaa : bbb : ccc : eee] ; comp=sigcomp ;branch=z9hG4bKnasiuen8 
Max-Forwards: 70 

P-Access-Network-Info : IEEE-802 . lib 

From : <sip : userl_publicl@homel . net > ; tag=2hiue 

To : <sip : userl_publicl@homel . net > 

Contact: <sip : [5555 :: aaa : bbb : ccc : eee] ; comp=sigcomp> ; reg-id=2; +sip . instance = " < 
urn: gsma : imei : 9042 0156- 025763 -0>;+g. 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- 

service . ims .icsi .mmtel 11 ; +g . 3gpp . ics= "principal 11 ; +g . 3gpp . access type="wlan2";expires=600000 ; + 
g . 3gpp . iut-controller 
Call-ID: E05133BD26DD 

Authorization: Digest username= "userl_private@homel . net " , realm= " registrar . homel . net " , 

nonce="", uri= " sip : registrar . homel . net " , response="" 
Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789 ; spi-s=12345678 ; port-c=1234 ; 

port-s=5678 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 1 REGISTER 
Supported: path, outbound, gruu 
Content-Length: 



11-12. SIP REGISTER request (P-CSCF#2 to S-CSCF) 

The P-CSCF forwards the SIP REGISTER request towards S-CSCF via I-CSCF. Likewise in message #2, P- 
CSCF#2 adds a Path header field with flow token and 'ob' parameter. 

13-15. SIP 401 (Unauthorized) response (S-CSCF to UE) 
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The authentication challenge is sent in the SIP 401 (Unauthorized) response towards the UE. 
16-18. SIP REGISTER request (UE to S-CSCF) 

The UE sends the protected SIP REGISTER request towards S-CSCF using contact#2. 
19-21. SIP 200 (OK) response (S-CSCF to UE) 

The S-CSCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful. 
22. SIP REGISTER request (S-CSCF to SCC AS) 

The S-CSCF sends a third party SIP REGISTER request to the SCC AS based on the initial filter criteria it received. 
Table A.3.2-22: SIP REGISTER request (S-CSCF to SCC AS) 



REGISTER sip: sccas.homel.net /2 . 

Via: SIP/2. 0/UDP scscf 1 .homel . net ; branch=z9hG499f fhy 
Max- Forwards : 70 

From: <sip : scscf 1 . homel . net> ; tag=538ya 
To : <sip : userl_publicl@homel . net > 
P-Access-Network-Info : IEEE-802 . lib 
Call-ID: lasdaddlrf jflslj40a222 

Contact: <sip : scscf 1 . homel . net> ; expires=600000 
CSeq: 87 REGISTER 

Content - Type : mult ipart /mixed ; boundary= " boundaryl " 
Content-Length: (...) 

- -boundaryl 

Content-Type: message/sip 

REGISTER sip : registrar . homel . net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 
[5555 : : aaa : bbb : ccc : eee] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 69 

P-Access-Network-Info : IEEE-802 . lib 

Path: <sip : VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf 1 .visitedl . net ; lr ;ob> 
Require: path 

P-Visited-Network- ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
From : <sip : userl_publicl@homel . net > ; tag=2hiue 
To : <sip : userl_publicl@homel . net> 

Contact: <sip: [5555: : aaa : bbb : ccc : eee] ; comp=sigcomp> ; reg- id=2 ; +sip . instance= " < 
urn : gsma : imei :90420156-025763-0>;+g. 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 
service . ims . icsi .mmtel" ; +g . 3gpp . ics= "principal " ; +g . 3gpp . accesstype 
="wlan2";expires=600000 ;+g. 3gpp . iut-controller 
Call -ID: apb0 3a0s0 9dkjdfglkj4 9111 

Authorization: Digest username= "userl_private@homel . net " , realm= " registrar . homel . net " , 

nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 

uri="sip : registrar .homel .net" , response= " 6 62 9f ae4 9393a053974 50978507c4ef 1 " 

CSeq: 3 REGISTER 

Supported: path, outbound, gruu 

Content-Length: 

- -boundaryl 

Content-Type: message/sip 
SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfl_p . homel . net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl . net ;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : eee] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Path : <sip : termOpcscf 1 . visitedl . net ; lr ; ob> 
Service-Route : <sip : origOscscf 1 . homel . net ; lr> 
From : <sip : userl_publicl@homel . net > ; tag=2hiue 
To : <sip : userl_publicl@homel . net> ; tag=2da87 
Call -ID: apb03a0s0 9dkjdfglkj4 9111 

Contact: <sip: [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; 

pub-gruu= " sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c91e6bf 6 " 

; temp-gruu= " sip : tgruu . 7hs== j d7vnzga5w7f a j sc7-a j d6f abzOf 8g5@example . com; gr " 

,- +sip . instance= " <urn : gsma : imei :90420156-025763-0>" ;+g. 3gpp . icsi-ref = "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; +g . 3gpp . accesstype="wlan2" 

; expires=600000 ; +g . 3gpp . iut-controller 

Supported: path, outbound 

Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 
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P-Associated-URI : <sip : userl_public2@homel . net> , <sip :userl_public3@homel . net> , <sip : +1-212 -555- 
llliohomel . net ;user=phone> 
CSeq: 3 REGISTER 
Content-Length: 

- -boundaryl- - 

23. SIP 200 (OK) response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third-party SIP REGISTER request. 

A. 4 Signalling flows for call origination for service 
continuity 

A.4.1 Session origination for CS calls 

An example flow for session origination for CS calls can be found in 3GPP TS 24.292 [4]. 

A. 5 Signalling flows for call termination for service 
continuity 

A. 5.1 Session termination using CS media 

An example flow for session termination using CS calls can be found in 3GPP TS 24.292 [4]. 

A.6 Signalling flows for PS-CS access transfer 
A.6. 1 PS-CS access transfer: CS-PS 

In this example, SC UE A has an ongoing session with remote UE B over CS bearer before access transfer. When SC 
UE connects to an IP-CAN, it decides to transfer the session over the new IP-CAN. 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 



88 



ETSI TS 124 237 V9.4.0 (2010-10) 



SCUE A 


cs 


PS 









Interworking 
entities 



Intermediate IM 
CN subsystem 
entities 



SCC AS 



UEB 



1 . SC UE A is on an active session with UE B. Call is anchored at SCC AS. 
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Figure A.6.1-1 : Signalling flow for PS-CS Access Transfer: CS to PS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A has an ongoing session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 

2. SC UE A connects to a new IP-CAN: 

The SC UE A decides to transfer the session over the new IP -CAN. The UE A obtains an IP address that it will 
use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using standard registration 
procedure and reserves resources in the new IP-CAN. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) - see example in table A.6.1-3 

The SC UE A sends an initial SIP INVITE request to request the new call replaces the existing call. 
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Table A.6.1-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : domain. xferOsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route: <sip : pcscfl . homel . net : 7531 ; lr >, <sip : origOscscfl . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 902 3 7 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip :userl_publicl@homel . net ; gr= urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91e6bf G> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.6.1-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE A (Step 3). 
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Table A.6.1-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip :userl_publicl@homel . net ;gr=urn :uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route: <scscf 1 . homel . net ; lr > , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net > , <tel : +l-237-555-llll> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value= " AyretyU0dm+6O2IrT5tAFrbHLso=02 3 5 51024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net > ; tag=1717777 

To: <tel : +l-237-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk50132 3 7 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip :user2_publicl@home2 . net ;gr=urn : uuid : 2ad8950e-4 8a5-4a74-8d99- 
ad76cc7f c74> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5 5 5 5 : : aaa : bbb : ccc : ddd 
s = 

c = IN IP6 5555: : aaa: bbb: ccc : ddd 

t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate EVI CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 
17. Media paths between UE A and UE B 

The media path is using the new IP-CAN. 
18-19. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a BYE request. 

20-22. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS 
bearer. 
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23-24. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities) 

A.6.2 PS-CS access transfer: PS-CS 

In this example, SC UE A has an ongoing session with remote UE B over PS bearer before access transfer which is 
anchored at SCC AS. When the SC UE attaches to the CS domain, it decides to transfer the session over the CS bearer 
without ICS capability. 
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Figure A.6.2-1 Signalling flow for PS-CS access transfer: PS-CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A is on an active session with UE B: 

There is an ongoing IP bearer between the SC UE and the remote end UE B. The call is achored at SCC AS. 

2. SC UE A attaches to the CS domain 

The SC UE attaches to the CS domain and decides to transfer the session over the CS bearer. 
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3. CC SETUP messages 

The SC UE sends the CC SETUP message with the static STN as the called party number. 

4. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
table A.6.2-4 

Table A.6.2-4: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 . homel . net ; branch=z9hG4bk731b87 
Max-Forwards: 70 

Route : <sip : icscf 1 . homel . net ; lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel: +1-237- 555 - 1111> ; tag=171828 
To: <tel: +l-237-555-3333> 
Call- ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Accept -Contact : * ; +g . 3gpp . icsi-ref ="urn%3Aurn- 7% 3gpp- service . ims . icsi .mmtel" 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip : mgcf 1 . homel . net ; gr> ; +g . 3gpp .icsi-ref = "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxptime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

5. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

7. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

8. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.6.2- 
8 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 
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Table A.6.2-8: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip :user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 
Max-Forwards: 67 

Route: <sip : scscfl . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Function- Addresses : ccf=[5555::b9 9:c88:d7 7:e66]; ccf = [5555 : :a55 :b44 : c3 3 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 
P-Charging-Vector : icid-value= "BzyretyU0dm+6O2IrT5tAFrbHLso=023551034 " ; orig- 

ioi= " type3homel . net " 
Privacy: none 

From: <tel: +1-23 7- 555 - 1111> ; tag=569812 
To: <tel : +l-237-555-2222>; tag=26545 
Call- ID: ddl3a0s0 9a2sdfglkj 490378 
Cseq : 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 

00a0c91e6bf 6> ; +g . 3gpp . icsi-ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow : 

Content-Type: Content-Length: 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVPF 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 
m=message TCP/MSRP 98 
a=accept-types : text/plain 



9. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

10. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

11. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

12-13. SIP ACK request (SCC AS to UE B via EVI CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

14-15. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 

16. CC CONNECT message (interworking entities to SC UE A) 

17. CC CONNECT ACKNOWLEDGE message (SC UE A to interworking entities) 
18-19. SIP ACK request (interworking entities to SCC AS via IM CN subsystem entities) 
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The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

20. Media paths between SC UE A and UE B: 

The CS bearer is setup while the PS bearer is still existing. 

21-22: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP -CAN, by sending a SIP BYE request to 
the IT-: A. 

23-24. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

25. Media paths between SC UE A and UE B 

Finally, the session is transferred from PS bearer to CS bearer. 



A.7 Signalling flows for PS-PS access transfer 
A. 7.1 Introduction 

The signalling flows for PS-PS access transfer demonstrate how a multimedia session is transferred from Source Access 
Leg to the Target Access Leg. The following signalling flows are included: 

- subclause A. 7. 2 shows an example when all media of an ongoing communication session and the associated 
signalling are transferred from Source Access Leg to the Target Access Leg; and 

- subclause A.7. 3 shows an example when not all media of an ongoing communication session are transferred 
from the Source Access Leg to the Target Access Leg. 



A. 7. 2 PS-PS access transfer with full media transfer 

The signalling flows shown in figure A.7. 2-1 describes the PS-PS access transfer procedure when all media of an 
ongoing communication session and the associated signalling are transferred from one contact address of an UE to a 
different contact address of the same UE. No lower-level mechanism to support the access transfer is assumed or 
needed. 

In this example the UE-1 is on an active multimedia session with the UE-2 via one IP-CAN. After changing to a new 
IP -CAN, obtaining a new IP address, and discovering a P-CSCF, the UE-1 reserves resources in new IP -CAN prior to 
initiating the PS-PS access transfer procedure. When the PS-PS access transfer procedure is completed, the UE-1 
continues the multimedia session with the UE-2 on the new IP -CAN. In this example, when attaching to the new IP- 
CAN, it is irrelevant whether the UE-1 uses the same P-CSCF or a new P-CSCF. 

NOTE 1: This scenario requires that the UE-1 and the IM CN subsystem support simultaneous multiple 
registrations and requires that the UE-1 supports dual mode operation. 

NOTE 2: In this example flow, each call leg is uniquely identified with a respective dialog identifier consisting of 
the Call-ID, From tag, and To tag. 
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Figure A.7.2-1 : Signalling flow for session handover 

NOTE 3: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE-1 is on an active session with UE-2 

The UE-1 is in an active session with the UE-2. The call is anchored in the SCC AS. It is irrelevant which 
endpoint initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call leg 
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over old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=774321". The UE-1 and UE-2 exchange media over the old IP-CAN, which is maintained while the UE-1 
initiates the handover procedure. 

2. UE-1 connects to new IP-CAN 

The UE-1 determines that a handover of the session is required. The UE-1 connects to the new IP -CAN. The 
UE-1 obtains an IP address that it will use for the signalling and media. 

3. UE-1 registers with intermediate IM CN subsystem entities over new IP-CAN 

The UE-1 registers with the S-CSCF over the new IP-CAN using the standard registration procedure. Depending 
on the UE-1 configuration, the discovery of the P-CSCF in the new IP-CAN can precede this. 

4. UE-1 acquires resources in new IP-CAN 

Based on the UE-1 and new IP -CAN capabilities, the UE-1 decides to use the same codec that was used over the 
old IP -CAN. The UE-1 reserves resources (e.g. QoS) in the new IP -CAN that will be needed for the signalling 
and transferred media, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.2-5 

The UE-1 sends initial SIP INVITE request with a new SDP offer to the UE-2 that indicates that the new call 
replaces the existing call. The initial SIP INVITE request establishes a dialog for signalling and specifies in the 
SDP the new contact address that will be used for media over the new IP-CAN. Upon sending the initial SIP 
INVITE request, the UE-1 is ready to receive the RTP packets either over the new IP-CAN or the old IP-CAN. 
The RTP packets can arrive over the new IP -CAN prior to the UE-1 receiving the SIP 200 (OK) response for the 
initial SIP INVITE request. 

Table A.7.2-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE tel : +1-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip :pcscf 1 . homel . net : 7531 ; lr ; comp=sigcomp> , <sip : origSscscf 1 . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net > 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl@homel . net > ; tag=171828 

To: <tel : +l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec-agree; replaces 

Replaces: me03a0s09a2sdf gj kl491777 ; to-tag=774321 ; f rom-tag=64727891 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91e6bf G> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = - 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 
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Request-URI: the tel-URI of the destination, i.e. the UE-2. 

Require: the "replaces" option tag indicate that the support for Replace header field is required. 
Replaces: specifies the existing call that will be replaced with the new call. 

SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that the 
resources in the new IP -CAN have been acquired. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.7.2-7 

The initial SIP INVITE request is forwarded from intermediate IM CN subsystem entities in the home network 
to the SCC AS. The SCC AS acts as a routeing B2BUA as specified in 3GPP TS 24.229 [2]. In this example the 
SCC AS includes the contents of the Contact header field from the received SIP INVITE request. 

Table A.7.2-7: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel : +1-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscf 1 .homel .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 67 

Route: <sip : sccas . homel . net ; lr> 

Record- Route : <sip:scscfl. homel . net ; lr> , <sip : pcscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net > , <tel : +l-212-555-llll> 
P -Access -Network- Info : Privacy : Require : replaces 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023551024 " ;orig- 
ioi=type3ashomel .net> 

P- Charging- Function- Addresses : ccf = [5555 : :b99 : c88 : d77 : e66] ; ccf = [5555 : : a55 : b44 : c33 : d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
From: <sip : userl_publicl@homel . net > ; tag=171828 
To: <tel : +l-212-555-2222> 
Call-ID: 
Cseq : 

Supported : 
Replaces : 
Contact : 
Allow : 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c = 

t = 

m= 

b= 

a= 

a= 

a= 

a= 

a= 

a= 

a= 

a= 



8. Remote leg update 

The SCC AS based on the content of the Replaces header field correlates the initial SIP INVITE request to the 
existing local and remote call legs of the existing concatenated end to end session between the UE-1 and UE-2. 
The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the UE-2 containing the new 
SDP offer that it has received from the UE-1. 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.2-9 
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The UE-2 is informed of the change in access leg by the SCC AS sending a SIP re-INVITE request to the S- 
CSCF. 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE-1 (Step 5). 

Table A.7.2-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip :user2_publicl@home2 . net ; gr=urn : uuid : 2ad8950e-4 8a5 -4a74 - 8d99-ad76cc7f c74 > SIP/2.0 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route : <scscf 1 . homel . net ;lr>,<sip:scscf2. home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P- Asserted- Identity : P -Access -Network- Info : Privacy : P- Charging- Vector : icid- 

value="BzyretyU0dm+6O2IrT5tAFrbHLso=02 3 551034 11 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net > ; tag=1717777 
To: <tel : +l-212-555-2222>, tag=4321 
Call -ID: dcl4bltl0b3teghmlk50 13333 
Cseq: 111 INVITE 
Supported : 

Contact : < sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- Ild0-a765- 
00a0c91e6bf G> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: Accept: application/sdp 
Content-Type : 
Content-Length: (...) 

v=0 

= 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 
s = - 

c= IN IP6 5555: : aaa: bbb: ccc : ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS:25.4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= des:qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a= rtpmap:96 telephone-event 
a= maxptime:20 



Route: The SIP re-INVITE request contains the saved list of Route header fields that the SCC AS has saved for 
the remote leg of the call. 

10. SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) - see example in table A.7.2-10 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 
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Table A.7.2-10: SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN 

subsystem entities) 



INVITE < sip :user2_publicl@home2 . net ; gr=urn : uuid : 2ad8 95 0e-4 8a5 -4a74 - 8d99-ad76cc7f c74 > SIP/2.0 
Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP sccas.homel.net; 

branch= z 9hG4bK3 3 2b3 3 . 3 ; 
Max-Forwards: 66 

Route : <sip:scscf2. home2 . net ; lr> , <sip :pcscf 2 . visited2 . net ; lr> 

P- Asserted- Identity : 

Privacy: none 

From: 

To: 

Call-ID: 

Cseq : Supported : Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a76 5- 

0a0c91e6bf 6> ; +g . 3gpp . icsi-ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel 11 
Allow : 
Accept : 

Content-TypeContent-Length : 

v= 

o= 

s = - 

c= 

t= 

m= 

b= 

a= 

a= 

a= 

a= 

a= 

a= 

a= 



11. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards the UE-2 by the intermediate IM 
CN subsystem entities. 

12. Media paths between UE-1 and UE-2 

The UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that the UE-1 is ready to 
receive the same media on a different contact address. Since the UE-2 has resources already available, it starts to 
send the media to the UE-l's contact address specified in the SDP offer immediately. 

The UE-1 will be receiving the RTP packets over new IP-CAN. However, the UE-1 can receive some out-of- 
sequence RTP packets over the old IP -CAN. The RTP packets are delivered to the codec in sequence. Once the 
UE-1 determine that no media will be received over the old IP-CAN (e.g. by examining the sequence numbers in 
the RTP headers), it can relinquish the resources that it has been using for incoming media on the old IP -CAN. 

The UE-1 sends the media to the UE-2 over the old IP-CAN. 

Resources used for signalling on the old IP -CAN are not released. 

13. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-2 has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 

15. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the SCC AS. 
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16. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

17. SIP ACK request (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

18. SIP ACK request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the UE- 
2. 

19. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header field that was received in the initial SIP INVITE request 
(step 5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. The SIP 200 (OK) response to the 
initial SIP INVITE request contains the SDP answer that is identical to the SDP answer that the SCC AS has 
received in the SIP 200 (OK) response to SIP re-INVITE request from the UE-2 (Step 13). 

20. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the UE-1. 

21. Media paths between UE-1 and UE-2 

The UE-1 receives the SIP 200 (OK) response containing the SDP answer that indicates that the UE-2 is ready to 
receive media. Since the UE-1 has already resources available, it starts to send media over new IP -CAN to the 
UE-2's contact address specified in the SDP answer immediately. 

The UE-1 can relinquish the resources that it has been using for outgoing media on the old IP-CAN. 
Resources used for signalling on the old IP -CAN are not released. 

22. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

The UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

23. SIP ACK request (-intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

24. SIP BYE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN, by sending a SIP BYE request to 
the UE-1. 

25. SIP BYE request (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP BYE request to the UE-1. 

26. SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the UE-1 sends a SIP 200 (OK) response over the old 
IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP -CAN. 

27. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 
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A. 7. 3 PS-PS access transfer with partial media transfer 

The signalling flows shown in figure A.7.3-1 describes the PS-PS access transfer procedure when not all media of an 
ongoing communication session are transferred from the Source Access Leg to the Target Access Leg. No lower-level 
mechanism to support the access transfer is assumed or needed. 

In this example, UE-1 is on an active multimedia session with UE-2 via one IP-CAN. After connecting to an additional 
IP -CAN, obtaining an additional IP address, discovering a P-CSCF, and performing registration in the IM CN 
subsystem, UE-1 reserves resources in the new IP -CAN prior to initiating the PS-PS access transfer procedure. When 
the PS-PS access transfer procedure is completed, UE-1 continues the multimedia session with UE-2 on both the old 
and the new IP-CANs. In this example, when attaching to the new IP-CAN, it is irrelevant whether the UE-1 uses the 
same P-CSCF or a new P-CSCF. 

NOTE 1: This scenario requires that UE-1 and the IM CN subsystem support simultaneous multiple registrations 
and requires that UE-1 supports dual mode operation. 
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Figure A.7.3-1 : Signalling flow for PS-PS session transfer with partial media transfer 

NOTE 2: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE-1 is on an active session with UE-2 

UE-1 is in an active session with UE-2. The call is anchored in the SCC AS. It is irrelevant which endpoint 
initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call leg over IP- 
CAN #1 is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=774321". UE-1 and UE-2 exchange media over the IP -CAN #1, which is maintained while the UE-1 initiates 
the session transfer procedure. 



2. UE-1 connects to IP-CAN #2 
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UE-1 connects to the new IP-CAN and obtains an IP address that it will use for the signalling and media. 

3. UE-1 registers with intermediate IM CN subsystem entities over IP-CAN #2 

UE-1 registers with the S-CSCF over the IP -CAN #2 using the standard registration procedure. The P-CSCF in 
the signalling path of this registration can be distinct from the one used in the signalling path over IP-CAN #1. 

4. UE-1 acquires resources in IP-CAN #2 

UE-1 decides to perform partial media transfer to the IP-CAN #2. Based on UE-1 and IP -CAN #2 capabilities, 
the UE-1 decides to use the same codec that was used over the IP -CAN #1 for the media components to be 
transferred. UE-1 ensures that the resources (e.g. QoS) in IP -CAN #2 that will be needed for the signalling and 
transferred media are available, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.3-5 

UE-1 sends initial SIP INVITE request with a new SDP offer to UE-2 and indicates that the video component is 
to be transferred to IP -CAN #2. The initial SIP INVITE request establishes a dialog for signalling and specifies 
in the SDP new contact address that will be used for media over IP -CAN #2. Upon sending the initial SIP 
INVITE request, UE-1 is ready to receive the RTP packets over both IP -CAN #1 and IP-CAN #2. 

Table A.7.3-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE tel : +1-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp = sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : sip : pcscf 1 . homel . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net > 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip :userl_publicl@homel . net> ; tag=171828 

To: <tel : +l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec-agree; tdialog 

Target-Dialog: me03a0s09a2sdf gj kl491777 ; remote-tag=774321 ; local-tag=64727891 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : < sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a76 5- 

0a0c91e6bf G> ; +g . 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = - 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio RTP/AVP 97 96 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
m=video 34 RTP/AVP 98 99 
b=AS : 75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Request-URI: the tel-URI of the destination, i.e. the UE-2. 

Require: the "tdialog" option tag indicate that the support for Target-Dialog header field is required. 
Target-Dialog: specifies the existing call that will be transferred. 
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SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that only the 
video component will be transferred and the resources in the new IP-CAN have been reserved. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The initial SIP INVITE request is forwarded from intermediate IM CN subsystem entities in the home network 
to the SCC AS. The SCC AS acts as a routeing B2BUA as specified in 3GPP TS 24.229 [2]. 

8. Remote leg update 

Based on the content of the Target-Dialog header field, the SCC AS correlates the SIP INVITE request for 
session transfer to the existing local and remote call legs of the existing concatenated end to end session between 
UE-1 and UE-2. The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the remote UE- 
2 containing the new SDP offer based on the partial media transfer request received from UE-1 and the 
negotiated SDP for the original session. 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3-9 

UE-2 is informed of the change in access leg by the SCC AS sending a re-INVITE request to the S-CSCF. 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is based on original SDP offer and the SDP offer that the SCC AS received in 
the initial SIP INVITE request from the UE-1 (Step 7). 
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Table A.7.3-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip :User2_publicl@home2 . net ; gr=urn : uuid : 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 0> 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 70 

Route: <scscf 1 . homel . net ; lr> , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net > , <tel : +l-212-555-llll> 
Privacy: none 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net> ; tag=1717777 

To: <tel : +l-212-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk50 13333 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- Ild0-a765- 

00a0c91e6bf 6> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

= 2987933100 2987933101 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = - 

t=o o 

m=audio 3456 RTP/AVP 97 96 

c = IN IP6 5555 :: aaa : bbb : ccc : eee 

b=AS : 25 . 4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= des:qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode- change -period=2 

a= rtpmap:96 telephone -event 

a= maxptime:20 

m=video 3400 RTP/AVP 98 99 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 

b=AS : 75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Route: The SIP re-INVITE request contains the saved list of Route header fields that the SCC AS has saved for 
the remote leg of the call. 

SDP: specifies the new IP address and ports used for the media components. In this case, the audio component is 
still using the original address and port while the video component is using the new IP address and new port 
allocated. 

10. SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 

11. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards UE-2 by the intermediate IM CN 
subsystem entities. 

UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that UE-1 is ready to receive 
video media on a different contact address. Since UE-2 has resources already available, it starts to send the 
media to UE-l's contact address specified in the SDP offer immediately. 

UE-1 starts receiving the video RTP packets over IP -CAN #2. However, UE-1 can receive some out-of-sequence 
video RTP packets over IP -CAN #1. The video RTP packets are delivered to the codec in sequence. Once UE-1 
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determine that no video will be received over IP-CAN #1 (e.g. by examining the sequence numbers in the RTP 
headers), it can relinquish the resources that it has been using for incoming video media on IP-CAN #1 . 

At the same time, UE-1 still sends both the audio and video media to UE-2 over IP -CAN #1. 

Resources used for signalling on IP -CAN #1 are not released. 

12. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) - see example in table A.7.3-12 

Upon receiving the SIP re-INVITE request containing the SDP offer, since UE-2 has all resources available, it 
sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

Table A.7.3-12: SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via : SIP/2 . 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK361k21 . 1 , 

SIP/2 . 0/UDP scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1 , 

SIP/2 . 0/UDP scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1 , 

SIP/2 . 0/UDP sccas .homel .net ;branch=z9hG4bK332b33 . 3 
Record- Route : <sip : pcscf 2 . visited2 . net : 50 88 ; lr ; comp=sigcomp> , <sip:scscf2. home2 . net ; lr> , 

<sip:scscfl .homel .net ; lr> 
P- Access -Network- Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=1717777 

To: <tel : +1-212 -555 -2222 >;tag=4321 

Call- ID: dcl4bltl0b3teghmlk5 013333 

CSeq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip :user2_publicl@home2 . net ; gr=urn :uuid : 2ad8950e-4 8a5-4a74 - 8d99- 

ad76cc7f c74> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933624 IN IP6 5555 : : eee : f f f : aaa : bbb 
s = - 

c=IN IP6 5555: :eee:fff : aaa : bbb 
t = 

m=audio 6544 RTP/AVP 97 96 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=video 10001 RTP/AVP 98 99 
b=AS : 75 

a=curr:qos local sendrecv 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 
a=rtpmap:98 H263 
a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 



13. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the SCC AS. 

15. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 
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The SCC AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re -INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

16. SIP ACK request (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

17. SIP ACK request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to UE-2. 

18. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3- 
18 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header field that was received in the initial SIP INVITE request 
(step 5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP 200 (OK) response. The SIP 200 (OK) 
response to the initial SIP INVITE request contains the SDP answer derived from the SDP answer that the SCC 
AS has received in the SIP 200 (OK) response to SIP re-INVITE request from UE-2 (Step 14). 

Table A.7.3-18: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , 
SIP/2 . 0/UDP pesef 1 .homel .net ;branch=z9hG4bK24 0f 34 . 1 , 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : <sip : sccas . homel . net ; lr> , <sip : scscf 1 . homel . net ; lr> , <sip :pcscf 1 . homel . net ; lr> 
Privacy: none 

From: <sip : userl_publicl@homel . net > ; tag=171828 
To: <tel : +1-212- 555-2222 >;tag=800 9 
Call- ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : < sip : user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 

ad76cc7f c74> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: eee : fff : aaa :bbb 
s = - 

c=IN IP6 5555 :: eee : fff : aaa :bbb 
t = 

m=audio RTP/AVP 97 96 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
m=video 10001 RTP/AVP 98 99 
b=AS : 75 

a=curr:qos local sendrecv 
a=curr:qos remote sendrecv 
a=des:qos mandatory local sendrecv 
a=des:qos mandatory remote sendrecv 
a=rtpmap:98 H263 
a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 



19. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to UE-1. 
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UE-1 receives the SIP 200 (OK) response containing the SDP answer indicating that UE-2 is ready to receive 
media. Since UE-1 has already resources available, it starts to send video media over IP-CAN #2 to UE-2's 
contact address specified in the SDP answer immediately. 

The UE-1 can relinquish the resources that it has been using for outgoing video media on IP-CAN #1. 
Resources used for signalling and audio media on IP-CAN #1 are not released. 

20. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

21. SIP ACK request ( intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

22. SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.3-22 

UE-1 updates the old call leg on IP-CAN #1 by sending a SIP re-INVITE request to the intermediate IM CN 
subsystem entities. 

Table A.7.3-22: SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE <sip :User2_publicl@home2 . net ; gr=urn : uuid : 2ad8 950e-4 8a5 -4a74 - 8d99-ad76cc7f c74 > SIP/2.0 
Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : eee] : 2468 ; comp=sigcomp ;branch=z9hG4bKashdnsl 
Max-Forwards: 70 

Route : sip : pcscf 1 . homel . net : 8765 ; lr ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
P- Access -Network- Info : 3GPP-UTRAN-FDD; utran-cell-id-3gpp=12 34 5 6ABCDE22 
Privacy: none 

From: <sip : userl_publicl@homel . net > ; tag=64727891 
To: <tel : +l-212-555-2222>; tag=774321 
Call -ID: me 3a0s0 9a2sdfgjkl4 91777 
Cseq: 101 INVITE 

Supported: lOOrel; precondition; tdialog 
Require: sec-agree; 
Proxy-Require : sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=12345678 ; portl=2468 
Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91e6bf 6> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933000 2987933001 IN IP6 5555 :: aaa :bbb : ccc : eee 
s = - 

c=IN IP6 5555 :: aaa : bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



23. SIP re-INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the SCC AS. 

24. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3- 
24 

The SCC AS updates the old call leg based on the SIP re-INVITE request and sends the SIP 200 (OK) response 
to the SIP re-INVITE request to the intermediate IM CN subsystem entities, using the content of the Via header 
field that was received in the SIP re-INVITE request (step 23). In this example the SCC AS includes the contents 
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of the Contact header field from the received SIP 200 (OK) response. The SIP 200 (OK) response to the SIP re- 
INVITE request contains the SDP answer derived from the SDP answer that the SCC AS previously received 
from UE-2 (Step 14). 

Table A.7.3-24: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK345b32 . 2 , 
SIP/2 . 0/UDP pcscfl .homel .net ;branch=z9hG4bK56 8f 3 5 . 1 , 

SIP/2 . 0/UDP [5555 : : aaa : bbb : ccc : eee] : 2468 ; comp=sigcomp;branch=z9hG4bKashdnsl 
Record-Route : <sccas . homel . net ; lr> , <sip : scscf 1 . homel . net ; lr> , <sip :pcscf 1 . homel . net ; lr> 
Privacy: none 

From: <sip : userl_publicl@homel . net > ; tag=64727891 
To: <tel : +1-212 -555 -2222 >;tag=774321 
Call -ID : me03a0s09a2sdfgjkl4 91777 
Cseq: 101 INVITE 

Supported: lOOrel; precondition 

Contact : < sip : user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 

ad7 6 cc 7 f c74> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933800 2987933801 IN IP6 5555 :: eee : fff : aaa : bbb 
s = - 

c = IN IP6 5555: :eee:fff : aaa : bbb 

t=o o 

m=audio 6544 RTP/AVP 97 96 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



25. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to UE-1. 

26. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the old call leg update with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

27. SIP ACK request ( intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 



A.8 Signalling flows for PS-PS access transfer in 
conjunction with PS-CS access transfer 

A.8.1 Introduction 

The signalling flows for PS-PS access transfer conjunction with PS-CS access transfer demonstrate how a multimedia 
session is tranferred from Source Access Leg to the Target Access Leg. The following signalling flows are included: 

subclause A. 8. 2 shows an example when a multimedia session is transferred from one IP-CAN to a new IP -CAN 
and the CS bearer respectively ; and 

- subclause A. 8. 3 shows an example when a multimedia session is transferred from one IP -CAN and CS bearer to 
a new IP -CAN. 
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A.8.2 PS - PS in conjunction with PS - CS Access Transfer: PS to 
CS 

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 before access transfer. 
When SC UE connects to a new IP-CAN#2, it decides to transfer the multimedia session over the new IP-CAN#2 and 
the CS bearer respectively. 
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Figure A.8.2-1 : Signalling flow for PS - PS in conjunction with PS - CS Access 

Transfer: PS to CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A has an ongoing multimedia session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over 
old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=774321". The UE A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE 
A initiates the handover procedure. 

Table A.8.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 

NOTE 2: To later show how the media is transferred to the new IP -CAN and CS bearer, only the SDP offer is 
shown in table A.8.2-1. 

Table A.8.2-1 : SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-2222 SIP/2.0 
Via: 

Max- Forwards : 
Route : 

P- Asserted- Identity : 

P-Charging-Vector : 

P-Access-Network-Info : 

Privacy : 

From: 

To: 

Call-ID: 
Cseq : 

Supported : 
Require : 
Proxy-Require : 
Security-Verif y : 
Contact : 
Allow : 
Accept : 
Content-Type : 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 
a=accept-types : text/plain 



2. SC UE A connects to a new IP-CAN#2: 

The SC UE A decides to transfer the multimedia session over the new IP -CAN and CS bearer respectively. The 
UE A obtains an IP address that it will use for the signalling and media. It registers with the S-CSCF over the 
new IP -CAN using multiple registrations procedure. Depending on the UE A configuration, the discovery of the 
P-CSCF in the new IP-CAN can be needed. Based on the UE A and new IP -CAN capabilities, the UE A decides 
to use the same codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new 
IP-CAN that will be needed for the signalling and transferred media, prior to sending the initial SIP INVITE 
request. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)- see example in table A.8.2-3 
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The SC UE A sends an initial SIP INVITE request with a STI and a new SDP offer to the UE B that indicates 
that the new call replaces the existing call. The initial SIP INVITE request establishes a dialog for signalling and 
specifies in the SDP a new contact address that will be used for non-realtime media over the new IP -CAN. Upon 
sending the initial SIP INVITE request, the UE A is ready to receive the RTP packets either over the new IP- 
CAN or the old IP -CAN. The RTP packets can arrive over the new IP-CAN prior to the SC UE are receiving the 
SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.8.2-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : f f f ] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : sip : pcscf 1 . homel . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip :userl_publicl@homel . net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip :userl_publicl@homel . net> ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490237 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip :userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91e6bf G> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 
Target -Dialog :me03a0s09a2sdfgjkl4 91777; to-tag=774 321 ; f rom-tag=64 72 78 91 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : fff 
s = 

t = 

m=audio RTP/AVP 97 96 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 

b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 

c = IN IP6 5555: : aaa : bbb : ccc : fff 

a=accept-types : text/plain 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the remote UE. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.8.2-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
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request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE A (Step 3). 

Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip :user2_publicl@home2 . net ; gr=urn : uuid : 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74>; SIP/2.0 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route: <scscf 1 . homel . net ; lr > , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> , <tel : +l-237-555-llll> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net> ; tag=1717777 

To: <tel : +l-237-555-2222>, tag=4321 

Call -ID: dcl4bltl0b3teghmlk5 0132 3 7 

Cseq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : < sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 

00a0c91e6bf 6> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 
v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : f f f 
s=t=0 

m=audio RTP/AVP 97 96 

c = IN IP6 5555: : aaa: bbb: ccc : ddd 

b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 

c = IN IP6 5555: : aaa : bbb : ccc : f f f 

a=accept-types : text/plain 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate EVI CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The non-realtime media is using the new IP -CAN while the realtime media path is still over the old IP-CAN. 

18. CC SETUP message (SC UE A to Interworking entities) 

The SC UE sends the CC SETUP message with the STN as the called party number. 
NOTE 3: STN is a PSI DN used by the UE to request a session transfer towards the SCC AS. 
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19. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
Table A.8.2-19 

Table A.8.2-19: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.homel.net; branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : icscf 1 . homel . net : 7531 ; lr ; comp=sigcomp> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel: +1-23 7- 555 - 1111> ; tag=171828 
To: <tel : +l-237-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj4903 3 3 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 

Contact : <sip : mgcf 2 . home2 . net ; gr> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Accept: application/sdp , application/3gpp- ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 



v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = 

c=IN IP6 5555 :: aaa : bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

20. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

21. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

22. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

23. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.8.2- 
23 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header 
field from the received SIP INVITE request. 
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Table A.8.2-23: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip :user2_publicl@home2 . net ;gr=urn : uuid : 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 
Max-Forwards: 67 

Route: <sip : scscfl . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Function- Addresses : ccf = [5555 : : b99 : c88 : d77 : e66] ; ccf = [5555 : :a55 :b44 : c3 3 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 
P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- 

ioi= " type3homel . net " 
Privacy: none 

From: <tel: +1-23 7- 555 - 1111> ; tag=171828 
To: <tel : +l-237-555-2222>; tag=26545 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 
Contact : < sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 
00a0c91e6bf G> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = 

t = 

m=audio 3456 RTP/AVP 97 96 
c=IN IP6 5555 :: aaa :bbb : ccc : eee 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 

c = IN IP6 5555: : aaa : bbb : ccc : f f f 

a=accept-types : text/plain 



24. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

25. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

26. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

27-28. SIP ACK request (SCC AS to UE B via EVI CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

29-30. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 

31. CC CONNECT message (interworking entities to SC UE A) 
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32. CC CONNECT ACKNOWLEDGEMENT message (SC UE A to interworking entities) 

33-34. SIP ACK request (interworking entities to SCC AS via IM CN subsystem entities) 

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

35-36: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP -CAN, by sending a BYE request to the 
UE A. 

37-38. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE SIP request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

39. Media paths between SC UE A and UE B 

Finally, the non-realtime media path is over the new IP -CAN and the realtime media is using the CS bearer. 

A.8.3 PS - PS in conjunction with PS - CS Access Transfer: CS to 
PS 

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 and CS bearer before 
access transfer. When SC UE connects to a new IP-CAN#2, it decides to transfer all the multimedia session over the 
new IP-CAN#2. 
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1 . SC UE A is on an active multimedia session with UE B. Call is anchored at SCC AS. 



-1 a.non-realtime media path over IP-CAN# 1 ■ 
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and decides to transfer the multimedia 
session over the new IP-CAN . It 
reserves resources in the new IP-CAN. 



-3.INVITE 



rl7b.CS bearer-^-W 



■24. DISCONNECT 

25. DISCONNECT 
response 




-14. SIP 200 (OK) INV im 
I 

15. SIP ACK 



19 SIP BYE 

I 
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Figure A.8.3-1 : Signalling flow for PS - PS in conjunction with PS - CS Access 
Transfer: CS to PS 



NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
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1. SC UE A has an ongoing multimedia session with remote UE B 

The non realmedia path is over old IP-CAN#1 and the realtime media path is over the CS bearer. The call has 
been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over old IP-CAN#1 
is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To tag=774321". The UE 
A and UE B exchange media over the old IP -CAN, which is maintained while the SC UE A initiates the 
handover procedure. 

2. SC UE A connects to a new IP-CAN#2 

The SC UE A decides to transfer the multimedia session over the new IP-CAN#2. The UE A obtains an IP 
address that it will use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using 
multiple registrations procedure. Depending on the UE A configuration, the discovery of the P-CSCF in the new 
IP-CAN can precede this. Based on the UE A and new IP -CAN capabilities, the UE A decides to use the same 
codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new IP-CAN that will 
be needed for the signalling and transferred media, prior to sending the initial SIP INVITE request. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)- see example in table A.8.3-3 

Upon sending the initial SIP INVITE request, the UE A is ready to receive the RTP packets either over the new 
IP-CAN or the old IP-CAN. The RTP packets can arrive over the new IP-CAN prior to the SC UE are receiving 
the SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.8.3-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : f f f ] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : sip : pcscf 1 . homel . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl@homel . net > ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID : Cb03a0s09a2sdfglkj49023 7 

Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree, replaces 
Proxy-Require: sec-agree 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
P- Preferred- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl@homel . net ; gr= urn : uuid :f81d4fae-7dec-lld0-a765- 

00a0c91e6bf G> ; +g . 3gpp . icsi -ref = "urn%3Aurn-xxx%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= "principal " ; 
Replaces: me03a0s09a2sdf gj kl491777 ; to-tag=774321 ; f rom-tag=64727891 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : fff 
s = 

c=IN IP6 5555 :: aaa : bbb : ccc : fff 

t = 

m=audio 3456 RTP/AVP 97 96a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 
a=accept-types : text/plain 



Request-URI: Contains the static STI. 
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4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STL The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the remote UE. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.8.3-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. In this example the SCC AS 
includes the contents of the Contact header field from the received SIP INVITE request. The SIP re-INVITE 
request contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE A (Step 3). 

Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip : user2_publicl@home2 . net ; gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2.0 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route: <scscf 1 . homel . net ; lr > , <sip : scscf 2 . home2 . net ; lr> , <sip : pcscf 2 . visited2 . net ; lr> 
P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> , <tel : +l-237-555-llll> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
P-Charging-Function-Addresses : 

From: <sip : userl_publicl@homel . net> ; tag=569812 
To: <tel : +l-237-555-2222>, tag=4321 
Call -ID: dcl4bltl0b3teghmlk5 0132 3 7 
Cseq: 111 INVITE 

Contact : <sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91eGbf G> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : f f f 

s = 

c = IN IP6 5555: : aaa : bbb : ccc : f f f 

t = 

m=audio 3456 RTP/AVPF 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxptime : 2 

m=message 7654 TCP/MSRP 98 
a=accept-types : text/plain 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 
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The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate EVI CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The multimedia is using the new IP -CAN. Resources used for signalling on the old IP-CAN#1 and CS bearer are 
not released. 

18-19. SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN#1, by sending a SIP BYE request 
towards the SC UE A. 

20-21. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN#1, the SC UE A sends a SIP 200 (OK) response over 
the old IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP-CAN. 

22-23. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request. 

24-25. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS 
bearer. 

26-27. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities) 
28. Media paths between UE A and UE B 

The multimedia session is using the new IP-CAN#2. 

A.9 Signalling flows for media adding/deleting for access 
transfer 

A.9.1 Introduction 

The signalling flows for media adding/deleting demonstrate how the media of a multimedia session is added or deleted. 
The following signalling flow is included: 

- subclause A. 9. 2 shows an example when the non-realtime media of a multimedia session over the IP -CAN is 
removed. 

A. 9. 2 Remote End Initiation case - Removing media from split CS 
and PS sessions 

As a precondition the SC UE A has a CS call and IMS multimedia session with the remote UE after session transfer in a 
manner that more than one session are presented to UE B as one IMS session by the SCC AS. 
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SC UE A is on an active multimedia session with UE B. Call is anchored at SCC AS. 
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Figure A.9.2-1 : Remote End Initiation case - Removing media from split CS and PS 

sessions 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
1. SC UE A has an ongoing multimedia session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 
Table A.9.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 
NOTE 2: To show how the media is removed, only the SDP offer is shown in this example. 
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Table A.9.2-1 : SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-2222 SIP/2.0 
Via : 

Max- Forwards : 
Route : 

P- Asserted- Identity: 
P- Charging- Vector : 
P-Access-Network-Info : 
Privacy : 
From: 
To : 

Call-ID: 
Cseq : 

Supported : 
Require : 
Proxy-Require : 
Security-Verify : 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 
s = 

c=IN IP6 5555 :: aaa : bbb : ccc : ddd 
t = 

m=message 7654 TCP/MSRP 98 
a=accept-types : text/plain 



2. SIP re-INVITE request (UE B to intermediate IM CN subsystem entities)- See example in table A.9.2.-2 

The remote UE B decides to remove the non-realtime media from the multimedia session. It uses standard IMS 
procedures to remove one or more PS media from the session. 
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Table A.9.2-2: SIP re-INVITE request (UE B to intermediate IM CN subsystem entities) 



INVITE < sip :userl_publicl@homel . net ;gr=urn :uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 
Max-Forwards: 67 

Route: <sip : scscfl . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-2222> 

P- Charging- Function- Addresses : ccf=[5555::b9 9:c88:d7 7:e66]; ccf = [5555 : :a55 :b44 : c3 3 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4ee] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 
P- Charging- Vector : icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=023 551024 " ; orig- 

ioi= " type3homel . net " 
P-Access-Network-Info : 
Privacy: none 

From: <tel: +1-237-555-2222; gr=hdg7777ad7af lzig8sf 7> ; tag=171828 

To: <tel : +l-237-555-llll> 

Call -ID : Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 
Contact : < sip :user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99- 

ad76cc7f c74> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 
s = 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 
m=message TCP/MSRP 98 
a=accept-types : text/plain 



3. SIP re-INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

4-5. SIP 200 (OK) response (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the remote 
UEB. 

6-7: SIP ACK request (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP ACK request to the SIP SIP 200 (OK) response and forwards it to the SCC AS. 

8-9: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the IP -CAN, by sending a SIP BYE request to the 
UE A. 

10-11. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the IP-CAN, the SC UE A sends a SIP 200 (OK) response over the IP- 
CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the IP-CAN. 

12. Media paths between SC UE A and UE B 

Finally, the non-realtime media path over the IP-CAN is removed. 
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A.1 Signalling flows for Inter-UE Transfer without 
establishment of Collaborative Session 

A.1 0.1 Introduction 

The signalling flows in the subclause demonstrate how a UE-1 can initiate the inter UE transfer of the complete session 
without Collaborative Session establishment. 

The example assumes that the UE-1 and UE-2 are under the control of the same subscriber. 

A.1 0.2 Complete transfer in services defining only originating 
session set up in UE 

In the example flow at the figure A. 10.2-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS. 
The session is established using an IMS communication service identified by ICSI urn:urn-7:3gpp-service.ims.icsi.iptv 
which is an IMS communication service which defines originating session set up in the UE only. 
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Figure A.10.2-1 : Signalling flow for inter UE transfer without Collaborative Session 

establishment 

NOTE 1: For clarity, the SIP 100 (Trying) responses and the SIP NOTIFY requests earring the message/sipfrag 
with SIP 100 (Trying) response are not shown in the signalling flow. 



1. UE-1 is in session with UE-3 
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There is a multimedia session comprising audio and video media between the UE-1 and the remote UE-3 
anchored at SCC AS. The session was established using IMS communication service identified by ICSI urn:urn- 
7:3gpp-service.ims.icsi.iptv. The dialog identifier of the session is AB03a0s09a2sdfglkj490333, remote- 
tag=Afgsdfg45, local-tag=U188gg. 

2. SIP REFER request initiating the inter UE transfer to UE-2 (UE-1 to Intermediate IM CN subsystem 
entities) - see example in table A. 10.2-2 

Table A.10.2-2: SIP REFER request (UE-1 to Intermediate IM CN subsystem entities) 



REFER sip : userohomel . net ; gr=urn : uuid : f 8 ld4f ae-7dec- Ild0-a76 5 -222222222222 SIP/2.0 
Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

P- Preferred- Identity : <sip : userohomel . net > 
From: <sip :user©homel . net> ; tag=171828 

To: < sip : userohomel . net ; gr=urn : uuid : f 8 ld4fae-7dec -Ild0-a76 5 -222222222222 > 
Call-ID: Asdasd231233 
Cseq: 4127 REFER 

Contact : <sip : userohomel . net ; gr=gr=urn : uuid : f 8 ld4fae- 7dec- lldO -a76 5- 111111111111 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Length: 

Refer-To : <sip : interUEtransf erOsccas . homel . net?Target- 

Dialog=AB03a0s09a2sdfglkj490333%3Bremote-tag=Afgsdfg45%3Blocal- 

tag=U188gg&Require=tdialog&P-Pref erred-Service=urn:urn-7 : 3gpp-service . ims . icsi . iptv&Accept- 
Contact = * %3b+g . 3gpp . icsi -ref %3d%2 2urn%2 53Aurn- 7%2 53gpp-service . ims . icsi . iptv%2 2 > 
Referred-By: sip : userohomel . net 



Request-URI: contains the GRUU of the UE-2 

Refer-To: contains the Inter UE Transfer SCC AS URItogether with Target-Dialog URI header field 
containing the dialog identifier of the session with UE-3, Require URI header field containing the "tdialog" and 
P-Preferred-Service and Accept-Contact URI header fields containing the ICSI of the service to be requested by 
UE-2. 

Contact: contains the GRUU of the UE-1 

3. Evaluation of initial filter criteria 

The S-CSCF evaluates originating initial filter criteria for the served user and as a result routes the SIP REFER 
request towards the SCC AS. 

4. SIP REFER request (Intermediate IM CN subsystem entities to SCC AS) 

5. The SCC AS authorizes the request and if authorization is passed successfully, the SCC AS forwards the 
SIP REFER request further 

6. -7. SIP REFER request (SCC AS to UE-2) 

8.-11. SIP 202 (Accepted) response to the SIP REFER request (UE-2 to UE-1) 

12. SIP INVITE request (UE-2 to intermediate IM CN subsystem entities) - see example in table A.10.2-12 
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Table A.10.2-12: SIP INVITE request (UE-1 to Intermediate IM CN subsystem entities) 



INVITE sip : interUEtransf erOsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : f f f ] : 13 57 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

P- Preferred- Identity : <sip : userohomel . net > 

From: <sip :user©homel . net> ; tag=171828 

To : <sip : interUEtransf erOsccas . homel . net> 

Call-ID: tq34gasgaegr 

Cseq: 4127 INVITE 

Contact : <sip : userohomel . net ;gr=urn : uuid : f 8 ld4fae-7dec- Ild0-a76 5 -222222222222 > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Target -Dialog: AB03a0s09a2sdf glkj 4 90333 ; remote- tag=Afgsdfg4 5 ; local -tag=U18 8gg 

Require : tdialog 

Content-Type: application/sdp 

Content-Length: (...) 

Supported: lOOrel, precondition 

P- Preferred- Service : urn : urn- 7 : 3gpp- service . ims . icsi . iptv 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . iptv" 
Referred-By: sip : userohomel . net 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : fff 
s = 

c = IN IP6 5555: : aaa : bbb : ccc : fff 

t=o o 

m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 

m=video 3400 RTP/AVP 98 99 
b=AS : 75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Request-URI: set to the URI in the Refer-To of the received SIP REFER request 
Contact: contains the GRUU of the UE-2 

Target-Dialog: set to the value of the Target-Dialog URI header field of the URI in the Refer-To of the 
received SIP REFER request 

Require: set to the value of the Require URI header field of the URI in the Refer-To of the received SIP 
REFER request 

P-Preferred-Service: set to the value of the P-Preferred-Service URI header field of the URI in the Refer-To 
of the received SIP REFER request 

Accept-Contact: set to the value of the Accept-Contact URI header field of the URI in the Refer-To of the 
received SIP REFER request 

13. Evaluation of initial filter criteria 

The S-CSCF evaluates originating initial filter criteria for the served user and as a result routes the SIP INVITE 
request towards the SCC AS. 

14. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

15. Remote Leg Update 
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Based on the STI in the Target-Dialog header field the SCC AS detects that the inter UE tranfer is being 
attempted and performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE. 

16-18. SIP re-INVITE request (SCC AS to UE-3 over intermediate EVI CN subsystem entities) 

The SCC AS acting as a routing B2BUA generates a SIP re-INVITE request based upon the received SIP 
INVITE request and the information previously stored against this session and routes it towards UE-3 via the 
intermediate IM CN subsystem entities. 

19-21. SIP 200 (OK) response (UE-3 to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-3 has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

22-24. SIP ACK request (SCC AS to UE-3 via intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE-3. 

25-26. SIP 200 (OK) response (SCC AS to UE-2 via intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the UE-2. 

27-28. SIP ACK request (UE-2 to SCC AS via intermediate IM CN subsystem entities) 

The UE-2 generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC AS. 

29. Media and IMS service control paths: 

The media path is now established between UE-2 and UE-3 and the IMS service control between UE-2 and SCC 
AS. 

30-33. SIP NOTIFY request (UE-2 to UE-1 over intermediate IM CN subsystem entities and SCC AS) 

The UE-2 generate the SIP NOTIFY request carrying the message/sipfrag body and send it towards UE-1. 

34-37. SIP 200 OK response to the SIP NOTIFY request (UE-1 to UE-2 over intermediate IM CN subsystem 
entities and SCC AS) 

38-39: SIP BYE request (SCC AS to UE-1 via intermediate IM CN subsystem entities) 

The SCC AS terminates the source access leg by sending a BYE request to the UE-1. 

40-41. SIP 200 (OK) response (UE-1 to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request, the UE-1 sends a SIP 200 (OK) response to the SCC AS. Subsequently, 
the UE-1 relinquishes all resources pertaining to the session. 

A. 10.3 Complete transfer in services defining terminating session 
set up in UE 

Editor's note: Complete transfer in services defining terminating session set up in UE is FFS 
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A.1 1 Signalling flows for establishment of collaborative 
session for inter-UE transfer 

A.1 1.1 Introduction 

This clause describes signalling flows for establishing a collaborative session. Two different scenarios have been 
considered: 

- the first scenario is when the collaborative session is established by transferring a media component from the 
controller UE to a controllee UE. This scenario is similar to the procedures described in subclause A. 12.2 with 
exception that upon receipt of the SIP REFER request from the controller UE, the SCC AS generates a SIP 
INVITE request instead of a SIP re-INVITE request and sends it to the controllee UE; and 

- the second scenario is described in subclause A. 1 1.2 and shows an example where the collaborative session is 
established by adding a new media component on a controllee UE. 

A.1 1 .2 Collaborative session establishment with new media 

There is an existing session with audio between controller UE, UE-1, and the remote UE. The controller UE establishes 
a collaborative session by adding a video media component to the controllee UE, UE-2. 
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Figure A.11.2: Controller UE establishes a collaborative session by adding a new 

media on controllee UE 

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1-2. SIP REFER request (from UE-1 to SCC-AS) 

The controller UE, UE-1 sends a SIP REFER request to the SCC AS containing a Refer-To header field 
containing the GRUU of controllee UE, UE-2 and a body parameter containing an m line for audio set to zero 
and an m line for video with the port number set to the discard port number "9" since the port number is 
unknown. The SIP REFER request also includes a Target-dialog header field containing the details of the dialog 
for the existing session between controller UE, UE-1 and the remote UE. 
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Table A.1 1.2-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : interUEtransf er@sccasl . homel . net SIP/2.0 




Via : 




To : sip : interUEtransf erSsccasl . homel . net 




From: sip:userl publiclohomel . net ; tag=2468 




Call -ID: Cb0 3a0s0 9a2sdfglkj 490333 




CSeq: 93809824 REFER 




Max-Forwards: 70 




P-Pref erred- Identity : sip:userl publicl@homel.net 




Ref er-To : <sip : userl public2@home2 . net ; gr=urn : uuid : f 81d4f ae- 7dec- 


Ild0-a762- 


0a0c91e6bf S?body=m%3Daudio%2 00%2 0RTP%2FAVP%2 096%0Dm%3Dvideo%2 09%2 0RTP%2FAVP%2 098%2 099> 


Require: target-dialog 




Target-dialog: Cb03a0s09a2sdf glkj 13579 ; remote-tag=abcdef ; local- 


tag=123456 


Ref erred-By : sip : userl_publicl@homel . net 




Contact : <sip :userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec- 


Ild0-a765- 


0a0c91ewxyz> ; +g . 3gpp . iut- controller 




Allow : 




Accept: message/sipf rag 




Content-Length: 




3-4. SIP 202 (Accepted) response (from SCC AS to UE-1) 



The SCC-AS sends a SIP 202 (Accepted) response to controller UE-1 as response to the SIP REFER request. 
5-6. SIP NOTIFY request (from SCC AS to UE-1) 

The SCC-AS sends a SIP NOTIFY request to UE-1 notifying implicit subscription to the SIP REFER request. 



Table A.1 1.2-5 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via : 

To : sip : userl_publicl@homel . net ; tag=24 6 8 

From : sip : interUEtransf erOsccasl . homel . net ; tag=13 579 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- St ate : active; expires=36 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (from UE-1 to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC-AS. 

9-10. SIP INVITE request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP INVITE request to the controllee UE, UE-2, adding video media and establishing a 
collaborative session. Since the URI parameters indicate that the port number for the video m-line is set to the 
discard port number "9", the SCC AS realizes that the port number of the remote UE is unknown and therefore 
adds an a-line to inactive in the SDP offer to prevent the controllee UE sending media to the remote UE. The 
SDP offer contains the audio media component on controller UE, UE-1 set to zero. 
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Table A.1 1.2-9 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip : user2_publicl@homel . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 SIP/2.0 
Via : 

Record-Route : sip : scc-as@homel . net 

To: sip : user2_publicl@homel . net ; 

From: sip : user3_public3@home3 . net ; tag=acegi 

Call-ID: 

CSeq: 

Max- Forwards : 

P-Asserted- Identity : "remote user" sip : user3_public3@home3 . net 
Require : 

Contact : sip : user3_public3@home3 . net ; gr=urn :uuid : f 81d4f ae- 17oct- llal-a678 - 0054c91eabcd 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 
t = 

m=audio RTP/AVP 
m=video 9 RTP/AVP 98 99 
a=inactive 
c = .0.0.0 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



The value of c-line is set to a domain name within the ".invalid" DNS top-level domain in case of IPv6 as 
described in draft-ietf-sipping-v6-transition [56]. 



11-12. SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controllee UE, UE-2, acknowledges the SIP INVITE request by sena ding SIP 200 (OK) response to the 
SCC-AS. In the following example, the controllee UE which has controller capabilities sends g.3gpp.iut- 
controller media feature tag in the Contact header field to indicate the support for the controller UE procedures. 

Table A.1 1.2-11 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 
Via: 

To : sip : user2_publicl@homel . net ; tag=xyzwv 
From: sip : user3_public3@home3 . net ; tag=acegi 
Call-ID: 
CSeq: 

P -Preferred- Identity : 

Contact : sip : userl_public2@home2 . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 

0a0c91e6bf 6 ; +g . 3gpp . iut -controller 
Allow: INVITE, PRACK, UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 145.23.77.88 
s = - 
t = 

m=audio RTP/AVP 
m=video 9 RTP/AVP 98 
a=inactive 
c=145 .23 . 77 . 88 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



13-14. SIP ACK request (from SCC-AS to controllee UE) 

The SCC-AS sends a SIP ACK request to the remote UE. 
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15-16. SIP re-INVITE request (from SCC-AS to remote UE) 

The SCC-AS sends a SIP re-INVITE request to the remote UE. 

Table A.11.2-15 SIP re-INVITE request (SCC-AS to remote UE) 



INVITE sip :user3_public3@home3 . net ; gr=urn : uuid : f 81d4f ae-17oct-llal-a678-0054c91eabcd SIP/2.0 
Via: 

To : sip : user3 _public3@home3 . net ; tag=66666 
From: sip : userl_publicl@homel . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- Ild0-a765- 00a0c91ewxyz 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s = - 
t = 

m=audio 1300 RTP/AVP 96 97 
c=IN IP4 123.45.67.89 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxptime : 2 

m=video 13 02 RTP/AVP 98 

C=IN IP4 145.23.77.88 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



17-18. SIP 200 (OK) response (from remote UE to SCC-AS) 

The remote UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC-AS. 

Table A.11.2-17 SIP 200 (OK) response (remote UE to SCC-AS) 



SIP/2.0 200 OK 

Via: 

To: 

From : 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : user3_public3@home3 . net ; gr=urn :uuid : f 81d4f ae- 17oct- llal-a678 - 0054c91eabcd 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123.112.67.87 
t = 

m=audio 3000 RTP/AVP 96 97 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:97 telephone-event 

a=maxpt ime : 2 

m=video 3 02 RTP/AVP 98 

b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



19-20. SIP ACK request (from SCC-AS to remote UE) 
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The SCC-AS sends a SIP ACK request to the remote UE. 

21-22. SIP re-INVITE request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP re-INVITE request to the controllee UE, UE-2 to inform the controllee UE about the 
port number for the video media component of the remote UE. The SCC AS adds an a-line set to active in the 
SDP offer. The SIP INVITE request contains a Referred-By header field containing the identity of UE-1 from 
the Referred-By header field from the SIP REFER request. 

NOTE 1: This SIP re-INVITE request is triggered by the SIP REFER request in steps 1-2. The previous SIP 

INVITE request was generated by the SCC AS due to third party call control to allow sending this SIP re- 
INVITE request. 

NOTE 2: Any other changes such as the IP address of the remote UE in case the remote UE uses different IP 
addresses for different media would also be updated in the SIP re-INVITE request. 

Table A.1 1.2-21 SIP re-INVITE request (SCC-AS to UE-2) 



INVITE sip : userl_public2@home2 . net ; gr=urn :uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 

Via: 

To: 

From : 

Call-ID: 

CSeq: 

Contact : sip : user3_public3@home3 . net ; gr=urn : uuid : f 81d4f ae-17oct-llal-a678-0 054c91eabcd 

Referred-By : sip : userl_publicl@homel . net 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.87 
s = - 

C=IN IP4 123.45.67.87 
t = 

m=audio RTP/AVP 96 97 
m=video 3 02 RTP/AVP 98 
b=AS : 75 
a=active 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



23-24. SIP 200 (OK) response (from controllee UE to SCC-AS) 



Table A.1 1.2-23 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To : 




From : 




Call-ID: 




CSeq: 




Contact: sip :userl_public2@home2 


net ;gr=urn :uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow : 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


145.23.77.88 


s = - 
t = 




m=audio RTP/AVP 




m=video 13 02 RTP/AVP 98 




c=145 .23.77.88 




b=AS : 75 




a=active 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 





25-26. SIP ACK request (from SCC-AS to controllee UE) 
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The SCC-AS sends a SIP ACK request to the controllee UE to acknowledge. 

27-28. SIP NOTIFY request (from SCC-AS to conroller UE, UE-1) 

When the media component is added to the controllee UE, UE-2, the SCC-AS sends a SIP NOTIFY request to 
the controller UE, UE-1 to inform about the success status of adding the media to the controllee UE, UE-2. 

Table A.1 1.2-27 SIP NOTIFY request (SCC-AS to UE-1) 

NOTIFY 
Via : 

To: sip :userl_publicl@homel . net ; tag = 13579 
From: sip : scc-as@homel . net ; tag=2468 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ;version=2.0 
Content-Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 

m=audio RTP/AVP 

m=video 13 02 RTP/AVP 98 99 

c=145 .23 . 77 . 88 

b=AS : 75 

a=active 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



29-30. SIP 200 (OK) response (from controller UE to SCC-AS) 

The controller UE acknowledges the NOTIFY request by sending a SIP 200 (OK) response to the SCC-AS. 



A.1 2 Signalling flows for media transfer within 
collaborative session for inter-UE transfer 

A.1 2.1 Introduction 

This subclause describes signalling flows for media transfer within collaborative sessions. Two different scenarios are 
considered in the clause: 

subclause A. 12.2 shows an example where a media component is transferred from the controller UE to the 
controllee UE; and 

- subclause A. 12.3 shows an example where a media component is transferred from one controllee UE to another 
controllee UE. 
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A. 12.2 Controller UE initiated media transfer from controller UE to 
controllee UE 
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-27. NOTIFY- 



-30. 200 OK- 



■(Audio). 



18. ACK- 



-(Video)- 



Figure A.12.2: Controller UE transfers a media on controllee UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1-2. SIP REFER request (SIP REFER request from UE-1 to SCC-AS) 

There is an existing session with audio and video between controller UE, UE-1 (123.45.67.89), and remote UE 
(132.54.76.98). The video component is unidirectional from the remote UE to the controller UE, UE1. The 
Controller UE attempts to transfer the video portion of this session to the controllee UE, UE-2. 
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Table A.1 2.2-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : interUEtransf er@sccasl . homel . net SIP/2.0 
Via : 

To : sip : interUEtransf er@sccasl . homel . net 

From: sip :userl_publicl@homel . net ; tag=13579 

Call -ID: Cb0 3a0s09a2sdfglkj 490333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P -Preferred- Identity : 

Ref er-To : <sip : userl_public2@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5- 0a0c91e6bf 6 ?body= 

m%3Daudio%2 00%2 0RTP%2FAVP%97%0Dm%3Dvideo%2 03 002%2 0RTP%2FAVP%2 098%2 099> 
Require: target-dialog 

Target -dialog: cb0 3a0s0 9a2sdf glkj 3215 76 ; remote -tag=abcdef ; local -tag=1234 56 
Contact : <sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a76 5- 

0a0c91ewxyz> ; +g . 3gpp . iut -controller 
Ref erred-By : sip : userl_publicl@homel . net 
Accept: application/sdp, message/sipf rag 
Content-Length: 



3-4. SIP 202 (Accepted) response (from SCC AS to UE-1) 

The SCC-AS sends a SIP 202 (Accepted) response to controller UE-1 as response to the SIP REFER request. 

5-6. SIP NOTIFY request (from SCC AS to UE-1) 

The SCC-AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request 
results. 

Table A.1 2.2-5 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2.0 
Via: 

To : sip :userl_publicl@homel . net ; tag=24680 

From : sip : interUEtransf erOsccasl . homel . net ; tag=13 579 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- St ate : active; expires=36 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (from UE-1 AS to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC-AS. 

9-10. SIP INVITE request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP INVITE request to the controllee UE, UE-2, to transfer video media. 
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Table A.1 2.2-9 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip :userl_public2@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 

To : sip : userl_public2@homel . net ; 
From: sip : scc-as@homel . net ; tag=12486 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Ref erred-By : sip : userl_publicl@homel . net 
Contact : 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123.112.67.87 
t = 

m=audio RTP/AVP 97 
m=video 3002 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



11-12. SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controllee UE, UE-2, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 



Table A.1 2.2-1 1 SIP 200 OK response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sip:userl public2@homel.net; 


tag = xyzwv 


From: sip : scc-as@homel . net ; tag = 


= 12486 


Call-ID: 




CSeq: 




P- Preferred- Identity : 




Contact: sip:userl public2@homel 


net ;gr=urn: uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow : 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


145 .23.77.88 


s = - 

c=145 .23.77.88 




t = 




m=audio RTP/AVP 97 




m=video 1302 RTP/AVP 98 99 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 





13-14. SIP re-INVITE request (from SCC-AS to remote UE) 

The SCC-AS sends a SIP re-INVITE request to the remote UE. 
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Table A.12.2-13 SIP INVITE request (SCC-AS to remote UE) 



INVITE sip :user3_public3@home3 .net SIP/2.0 
Via : 

To: sip : user3_public3@home3 . net ; tag = 66666 
From: sip : scc-as@homel . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 0a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.45.67.89 
s = - 
t = 

m=audio 1300 RTP/AVP 96 97 
c=IN IP4 123 .45.67.89 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone -event 
a=maxptime : 2 

m=video 1302 RTP/AVP 98 99 
C=IN IP4 145 .23.77.88 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



15-16. SIP 200 (OK) response (from remote UE to SCC-AS) 

The remote UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC-AS. 

Table A.12.2-15 SIP 200 (OK) response (remote UE to SCC-AS) 



SIP/2.0 200 OK 

Via : 

To: 

From: 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : user3_public3@home3 . net 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123 . 112 .67.87 
t = 

m=audio 3000 RTP/AVP 96 97 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=video 3 02 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



17-18. SIP ACK request (from SCC-AS to remote UE) 

The SCC-AS sends a SIP ACK request to the remote UE. 
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19-20. SIP ACK request (from SCC-AS to controllee UE; UE-2) 

The SCC-AS sends a SIP ACK request to the remote UE. 
21-22. SIP re-INVITE request (from SCC-AS to controller UE; UE-1) 

The SCC-AS sends a SIP re-INVITE request to the controller UE. 

Table A.1 2.2-21 SIP INVITE request (SCC-AS to UE-1) 



INVITE sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2.0 

Via: 

To: 

From : 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t = 

m=audio 2000 RTP/AVP 96 97 

b=AS:25.4 

a=rtpmap:96 AMR 

a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:97 telephone -event 

a=maxptime : 2 

m=video RTP/AVP 98 99 

a=sendonly 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



23-24. SIP 200 (OK) response (from UE-1 to SCC-AS) 

The controller UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC- 
AS. 

25-26. SIP ACK request (from SCC-AS to UE-1) 

The SCC-AS sends a SIP ACK request to the controllel UE, UE-1 in response to the SIP 200 (OK) response. 

27-28. SIP NOTIFY request (from SCC-AS to conroller UE, UE-1) 

The SCC-AS sends a SIP NOTIFY request to controller UE, UE-1 to inform about the success status of the inter - 
UE transfer. 
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Table A.1 2.2-27 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91ewxyz SIP/2.0 
Via : 

To: sip : userl_publicl@homel . net ; tag=24680 

From : sip : interUEtransf erOsccasl . homel . net ; tag=13 579 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 

v=0 
s = - 

m=audio RTP/AVP 97 
m=video 1302 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



29-30. SIP 200 (OK) response (from controller UE to SCC-AS) 

The remote UE acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC-AS. 

A.1 2.3 Controller UE initiated media transfer from controllee UE to 
another controllee UE with subscription to dialog events 

The signalling flow in figure A. 12.3 describes the procedures for media transfer from one controllee UE to another 
controllee UE with presistant subscription to dialog event. 

NOTE 1 : For brevity not all SIP NOTIFY requests sent as a result of the subscription to the dialog event package 
are shown. 
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14. NOTIFY 

15. 200 OK 
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I 



-31. 200 OK- 
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—35. NOTIFY — 
— 38. 200 OK — 
-39. Re-INVITE- 
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-45. Re-INVITE- 
— 48. 200 OK — 
49. ACK 



-51. NOTIFY- 
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<Audio 2)- 



34. ACK- 



-(Audio 1, Video)- 



Figure A.12.3: Controller UE transfers a media from one controllee UE to another 

controllee UE 

1-2. SIP SUBSCRIBE request (from controller UE to SCC-AS) - see example in table A.12.3-1 

In order that the controller UE fetches the information about the session descriptions of the UEs within the 
collaborative session, the controller UE subscribes to the existing dialog between the controller UE and the SCC 
AS. 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 144 ETSI TS 124 237 V9.4.0 (2010-10) 



Table A.1 2.3-1 SIP SUBSCRIBE request (controller UE to SCC-AS) 



SUBSCRIBE sip: scc-as@homel.net SIP/2.0 






Via : 






To: sip : scc-as@homel . net ; tag= 24680 






From: sip:userl publicl@homel.net; tag=13579 






Event: dialog; call-id=" cb03a0s0 9a2sdfglkj 321576 " , 


from-tag="54321' 


; to-tag="123456" ; 


include -session- description 






Call -ID: Cb03a0s0 9a2sdfglkj4903 3 3 






CSeq: 1 SUBSCRIBE 






Max-Forwards: 70 






P -Preferred- Identity : 






Require: target-dialog 






Expires: 36 






Target -dialog : cb0 3a0s0 9a2sdf glkj 3215 76 ; remote -tag= 


abcdef ; local-tag= 


123456 


Contact: sip:userl publicl@homel . net ; gr=urn : uuid : f £ 


ld4f ae-7dec-lld0- 


a765-0 0a0c91ewxyz 


CSeq: 






Allow : 






Accept : application/dialog- info+xml 






Content-Length: 







3-4. SIP 200 (OK) response (from SCC-AS to controller UE) 

The SCC AS acknowledges the SIP SUBSCRIBE request by sending a SIP 200 (OK) response to the controller 
UE. 

5-6. SIP NOTIFY request (from SCC-AS to controller UE) - see example in table A.12.3-5 

The SCC AS sends a SIP NOTIFY request containing SDP for the remote UE so that the controller UE has the 
current state of the media for the collaborative session. 
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Table A.1 2.3-5 SIP NOTIFY request (SCC-AS to controller UE) 



NOTIFY sip :userl_publicl@homel . net SIP/2.0 




Via : 




To: sipiuserl publicl@homel.net; tag=13579 




From: sip : scc-as@homel . net ; tag= 24680 




Cal 1 - ID : 




CSeq: 




Max- Forwards : 




P- Asserted- Identity: 




Require : 




Contact: sip: scc-as@homel.net 




Allow: 




Event : dialog 




Content-Type : application/dialog- info+xml 




Content-Length: (...) 




<?xml version=" 1 . " ?> 




<dialog- info xmlns= "urn : ietf : params : xml : ns : dialog- info" 




version= " " 




state="full" 




entity= " sip : scc-as@homel . net " > 




<dialog id="xxxx" call-id="f fafa" local-tag="dd" remote- tag= "ee" > 




<state>conf irmed</state> 




<local> 




<identity display="controllee UE" >sip : user2 publicl@homel . net</identity> 


< target >sip : user 2 public l@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO 


-a765- 


0a0c91e6bf 6</ target > 




< session- description type= " application/ sdp " > 




v=0 




o=- 1027933615 1027933615 IN IP4 123.112.67.87 




s = - 
t = 




m=audio 49174 RTP/AVP 96 97 




c=IN IP4 123.45.67.89 




b=AS : 25 . 4 




a=rtpmap:96 AMR 




a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 




a=rtpmap:97 telephone-event 




a=maxptime : 2 




m=audio 44552 RTP/AVP 96 97 




c=IN IP4 123.45.67.89 




b=AS : 25 . 4 




a=rtpmap:96 AMR 




a=fmtp:96 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 




a=rtpmap:97 telephone-event 




a=maxptime : 2 




m=video 1009 RTP/AVP 98 99 




c=IN IP4 123.112.67.87 




a=sendonly 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 




</session-description> 




</local> 




<remote> 




<identity display= " remote UE" >tel : +1-237- 555 -2222</identity> 




< target >sip : user2 publicl@home2 . net ; gr=urn :uuid : 2ad8950e-4 8a5-4a74 


-8d99- 


ad76cc7fc74< /target > 




<session-description type="application/sdp" > 




v=0 




o=- 1027933615 1027933615 IN IP4 123.112.67.87 




s = - 
t = 




m=audio 49174 RTP/AVP 96 97 




c= IN IP4 132.54.76.98 




b=AS:25.4 




a=rtpmap:96 AMR 




a=fmtp : 96mode-set=0 ,2,5,7; mode -change -per iod=2 




a=rtpmap:97 telephone-event 




a=maxptime : 2 




m=audio 44552 RTP/AVP 96 97 




b=AS:25.4 




a=rtpmap:96 AMR 




a=fmtp : 96mode-set=0 ,2,5,7; mode -change -per iod=2 




a=rtpmap:97 telephone-event 
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a=maxptime : 2 

c= IN IP4 132.54.76.98 

m=video 1009 RTP/AVP 98 99 

c= IN IP4 132.54.76.98 

a=sendonly 

b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 

< /sess ion- de script ion> 
< /remote > 
</dialog> 
< /dialog- info > 



7-8. SIP 200 (OK) response (from controllee UE-2 to SCC-AS) 

The controller UE-1 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC 
AS. 

9-10. SIP REFER request (UE-1 to SCC-AS) - see example in table A.12.3-9 

There is an existing session with audio 1 and audio 2 between UE-2 (123.45.67.89) and the remote UE 
(132.54.76.98). The video component is unidirectional from the remote UE to the controllee UE, UE-3 
(123.1 12.67.87). The Controller UE attempts to transfer the audio 1 portion of this session to the controllee UE, 
UE-3. 

Table A.12.3-9 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : scc-as@homel . net SIP/2.0 
Via : 

To: sip : scc-as@homel . net ; tag= 24680 

From: sip : userl_publicl@homel . net ; tag=13579 

Call- ID: Cb03a0s09a2sdfglkj4903 3 3 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : sip : userl_publicl@homel . net 

Refer- To : <sip :userl_public3@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a765- 
0a0c91e6bf 6body=m%3Daudio%2 00%2 0RTP%2FAVP%2 00%0Dm%3Daudio%2 
4 9174%2 0RTP%2FAVP%2 096%0Dm%3Dvideo%2 01009%2 0RTP%2FAVP%2 098%2 099> 

Require: target-dialog 

Target -dialog: cb03a0s0 9a2sdf glkj 3215 76 ; remote -tag=abcdef ; local -tag=1234 56 
Contact : <sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a76 5- 

0a0c91ewxyz> ; +g . 3gpp . iut- controller 
Ref erred-By : sip : userl_publicl@homel . net 
Accept: message/sipf rag 
Content-Length: 



11-12. SIP 202 (Accepted) response (from SCC AS to UE-1) 

The SCC-AS sends a SIP 202 (Accepted) response to controller UE-1 as response to the SIP REFER request. 

13-14. SIP NOTIFY request (from SCC AS to UE-1) - see example in table A.13.3-13 

The SCC-AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request 
results. 
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Table A.12.3-13 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via : 

To : sip : userl_publicl@homel . net ; tag=24680 
From : sip : scc-as@homel . net ; tag=13 579 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- St ate : active ; expires=3600 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



15-16. SIP 200 (OK) response (from UE-1 AS to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC-AS. 

17-18. SIP INVITE request (from SCC-AS to UE-3) - see example in table A.12.3-17 

Since the message 9-10 contains a Refer-to header field addressed to UE-3 and the URI paramaters, listing an 
audio line which is not currently supported by another controllee UE than UE-2, the SCC AS realizes the 
procedure is for transferring the media from that controllee UE (UE-2) to controllee UE (UE-3). The SCC-AS 
sends a SIP INVITE request to the controllee UE, UE-3, to transfer the audio media component. The SDP in the 
SIP INVITE request lists the media lines within the collaborative session. In order to avoid UE-3 to start 
sending audio to the remote UE, the SCC-AS adds an a-line to inactive in the SDP offer. 

Table A.12.3-17 SIP INVITE request (SCC-AS to UE-3) 



INVITE sip :userl_public3@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 

To : sip : userl_public3@homel . net ; 
From: sip : scc-as@homel . net ; tag=12486 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t=0 

m=audio 49174 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a= sendonly 
b=RR : 

b=RS : 0m=audio RTP/AVP 
m=video 1009 RTP/AVP 98 99 
a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



19-20. SIP 200 (OK) response (from UE-3 to SCC-AS) - see example in table A.12.3-19 

The controllee UE, UE-3, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 
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Table A.12.3-19 SIP 200 (OK) response (UE-3 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sipiuserl public3@homel.net; 


tag = xyzwv 


From: sip : scc-as@homel . net ; tag 


= 12486 


Call - ID : 




CSeq: 




P-Pref erred- Identity : 




Contact: sip:userl public3@homel 


. net;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123 . 112 .67.87 


s = - 

c=123 . 112 .67.87 




t = 




m=audio 3 02 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 




a=recvonly 




m=audio RTP/AVP 




m=video 1302 RTP/AVP 98 99 




a=recvonly 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 





21-22. SIP ACK request (from SCC-AS to UE-3) 

The SCC-AS sends a SIP ACK request to UE-3 to acknowlege. 
23-24. SIP re-INVITE request (from SCC-AS to controllee UE, UE-2) - see example in table A.12.3-23 

The SCC AS sends a SIP re-INVITE request to controllee UE, UE-2 to put Audio 1 on hold. 

Table A.12.3-23 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip : userl_public2@home3 . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 SIP/2.0 
Via: 

To: sip : userl_public2@homel . net ; 
From: sip : scc-as@homel . net ; tag=12386 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123.112.67.87 
t = 

m=audio 49174 RTP/AVP 96 97 
a=sendonly 
b=RR : 
b=RS : 

m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a=sendonly 
b=RR : 



25-26. SIP 200 (OK) response (from UE-2 to SCC-AS) - see example in table A.12.3-25 

The controllee UE, UE-2, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 149 ETSI TS 124 237 V9.4.0 (2010-10) 



Table A.1 2.3-25 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sipiuserl public2@homel.net; 


tag = xyzwv 


From: sip : scc-as@homel . net ; tag 


= 12486 


Call - ID : 




CSeq: 




P-Pref erred- Identity : 




Contact: sip:userl public2@homel 


. net;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123.45.67.89 


s = - 

c=IN IP4 123.45.67.89 




t = 




m=audio 32324 RTP/AVP 96 97 




a=recvonly 




m=audio 34002 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 




a=recvonly 





27-28. SIP ACK request (from SCC-AS to UE-2 ) 

The SCC -AS sends a SIP ACK request to UE-2 to acknowlege. 
29-30 SIP re-INVITE request (from SCC-AS to remote UE) - see example in table A.12.3-29 

The SCC-AS sends a SIP re-INVITE request to the remote UE. 

Table A.12.3-29 SIP INVITE request (SCC-AS to remote UE) 



INVITE sip : user2_publicl@home3 . net ; SIP/2 . 
Via: 

To : sip : user2_publicl@home2 . net ; tag=66666 
From: sip : scc-as@homel . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 
t = 

m=audio 3 02 RTP/AVP 96 97 
c= IN IP4 123 . 112 .67.87 
a=rtpmap:0 PCMU/8000 
m=audio 34 02 RTP/AVP 96 97 
C=IN IP4 123.45.67.89 
A=rtpmap:0 PCMU/8000 
m=video 1302 RTP/AVP 98 99 
c= IN IP4 123 . 112 .67.87 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=recvonly 



31-32. SIP 200 (OK) response (from remote UE to SCC-AS) - see example in table A.12.3-31 

The remote UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC-AS. 
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Table A.1 2.3-31 SIP 200 (OK) response (remote UE to SCC-AS) 



SIP/2.0 200 OK 

Via : 

To : 

From: 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : user2_publicl@home2 . net ; 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c= IN IP4 132.54.76.98 
t = 

m=audio 49174 RTP/AVP 96 97 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=f mtp : 96mode- set=0 ,2,5,7; mode -change -per iod=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
m=video 1009 RTP/AVP 98 99 
a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 
a=sendonly 



33-34. SIP ACK request (from SCC-AS to remote UE) 

The SCC-AS sends a SIP ACK request to the remote UE. 

35-36. SIP NOTIFY request (from SCC-AS to controller UE) - see example in table A.12.3-35 

The SCC AS sends SIP NOTIFY request containing SDP for the remote UE so that the controller UE can be 
aware about the change of state of the media for the collaborative session. 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 151 ETSI TS 124 237 V9.4.0 (2010-10) 



Table A.1 2.3-35 SIP NOTIFY request (SCC-AS to controller UE) 



NOTIFY sipiuserl publicl@homel.net; 




Via : 




To: sipiuserl publicl@homel.net; tag=13579 




From: sip : scc-as@homel . net ; tag= 24680 




Cal 1 - ID : 




CSeq: 




Max- Forwards : 




P- Asserted- Identity: 




Require : 




Contact: sip: scc-as@homel.net 




Allow: 




Event : dialog 




Content-Type : application/dialog- info+xml 




Content-Length: (...) 




<?xml version=" 1 . " ?> 




<dialog- info xmlns= "urn : ietf : params : xml : ns : dialog- info" 




version= " 1 " 




state="full" 




entity= " sip : scc-as@homel . net " > 




<dialog id="xxxx" call-id="f fafa" local-tag="dd" remote- tag= "ee" > 




<state>conf irmed</state> 




<local> 




<identity display="controllee UE" >sip : user2 publicl@homel . net</identity> 


< target >sip : user2 public IShomel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO 


-a765- 


0a0c91e6bf 6</ target > 




< session- description type= " application/ sdp " > 




v=0 




o=- 1027933615 1027933615 IN IP4 123.112.67.87 




s = - 
t = 




m=audio 49174 RTP/AVP 96 97 




c=IN IP4 123.45.67.89 




b=AS : 25 . 4 




a=rtpmap:96 AMR 




a=f mtp : 96mode- set=0 ,2,5,7; mode -change -per iod=2 




a=rtpmap:97 telephone-event 




a=maxptime : 2 




m=audio 44552 RTP/AVP 96 97 




c=IN IP4 123.45.67.89 




b=AS : 25 . 4 




a=rtpmap:96 AMR 




a=fmtp : 96mode-set=0 ,2,5,7; mode -change -per iod=2 




a=rtpmap:97 telephone-event 




a=maxptime : 2 




m=video 1009 RTP/AVP 98 99 




c=IN IP4 123.112.67.87 




a=sendonly 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 




< /sess ion- de script ion> 




</local> 




<remote> 




<identity display=" remote UE" >tel : +1-237- 555 -2222</identity> 




< target >sip : user2 publicl@home2 . net ; gr=urn :uuid : 2ad8950e-4 8a5-4a74 


-8d99- 


ad76cc7fc74< /target > 




<session-description type="application/sdp" > 




v=0 




o=- 1027933615 1027933615 IN IP4 123.112.67.87 




s = - 
t = 




c= IN IP4 132.54.76.98 




m=audio 49174 RTP/AVP 96 97 




b=AS:25.4 




a=rtpmap:96 AMR 




a=fmtp : 96mode-set=0 ,2,5,7; mode -change -per iod=2 




a=rtpmap:97 telephone-event 




a=maxptime : 2 




m=audio 44552 RTP/AVP 96 97 




b=AS:25.4 




a=rtpmap:96 AMR 




a=fmtp : 96mode-set=0 ,2,5,7; mode -change -per iod=2 




a=rtpmap:97 telephone-event 
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a=maxptime : 2 

m=video 1009 RTP/AVP 98 99 

a=sendonly 

b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 

</session-description> 
</remote> 
</dialog> 
< /dialog- info > 



37-38. SIP 200 (OK) response (from controllee UE-2 to SCC-AS) 

The controller UE-1 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC 
AS. 

39-40. SIP re-INVITE request (from SCC-AS to controllee UE, UE-2) - see example in table A.12.3-39 

The SCC-AS sends a SIP re_INVITE request to UE-2 to remove the audio 1 media component. 

Table A.12.3-39 SIP INVITE request (SCC-AS to UE-2) 



INVITE sip : userl_public2@home3 . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via: 

To: sip : userl_public2@homel . net ; 
From: sip : scc-as@homel . net ; tag=12386 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123.112.67.87 
t = 

m=audio RTP/AVP 
m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 



41-42. SIP 200 (OK) response (from UE-2 to SCC-AS) - see example in table A.12.3-41 

The controllee UE, UE-2, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to SCC- 
AS. 
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Table A.1 2.3-41 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Vis : 




To: sip : userl_public2@homel . net ; 


tag = xyzwv 


From: sip : scc-as@homel . net ; tag = 


= 12486 


Call - ID : 




CSeq: 




P- Preferred- Identity : 




Contact: sip:userl public2@homel 


net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123 .45.67.89 


s=- 

c=IN IP4 123.45.67.89 




t = 




m=audio RTP/AVP 




m=audio 34002 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 





43-44. SIP ACK request (from SCC-AS to UE-2) 

The SCC -AS sends a SIP ACK request to UE-2 to acknowlege. 
45-46. SIP reJNVITE request (from SCC-AS to controllee UE; UE-3) - see example in table A.12.3-45 

The SCC-AS sends a SIP reJNVITE request to UE-3 to activate the audio 1 media component. 

Table A.12.3-45 SIP re-INVITE request (SCC-AS to UE-3) 



INVITE sip :userl_public3@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 

To : sip : userl_public3@homel . net ; 
From: sip : scc-as@homel . net ; tag=12486 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Ref erred-By : sip : userl_publicl@homel . net 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123.112.67.87 
t = 

m=audio 49174 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a= sendrecv 
m=audio RTP/AVP 
m=video 1009 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=sendonly 



NOTE 2: This SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 

was generated by the SCC AS due to third party call control to allow sending this SIP re-INVITE request. 

47-48. SIP 200 (OK) response (from controllee UE; UE-3 to SCC AS) 

Controllee UE, UE-3 sends a SIP 200 (OK) response to the SCC AS. 
49-50. SIP ACK request (from SCC-AS to UE-3) 
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The SCC-AS sends a SIP ACK request to the remote UE. 

51-52. SIP NOTIFY request (from SCC-AS to controller UE) - see example in table A.12.3-51 

The SCC AS sends a SIP NOTIFY request containing SDP of the SIP 200 (OK) response received from the 
controllee UE; UE-3. 

Table A.12.3-51 SIP NOTIFY request (SCC-AS to controller UE) 



NOTIFY sip : userl_publicl@homel . net ; 
Via : 

To: sip :userl_publicl@homel . net ; tag=13579 
From: sip : scc-as@homel . net ; tag= 24680 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Content-Type: message/sipf rag ; version=2 . ; 
Content-Length: (...) 

SIP/2.0 200 OK 

To: sip : userl_public3@homel . net ; tag = xyzwv 
From: sip : scc-as@homel . net ; tag = 12486 
Call-ID: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=123 . 112 .67.87 
t = 

m=audio 3002 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
m=audio RTP/AVP 
m=video 13 02 RTP/AVP 98 99 
a=recvonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



53-54. SIP 200 (OK) response (from controller UE to SCC-AS) 

The controller UE acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC AS. 

A.12.3A Controller UE initiated media transfer from controllee UE 
to another controllee UE 

The signalling flow in figure A. 12. 3 A describes the procedures for media transfer from one controllee UE to another 
controllee UE. 
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— 14. SIP ACK 



-16. SIP r^- INVITE- 

-17. SIP 200 re- INVITE - 

20. SIP ACK 



-28. SIP re- INVITE— 

-29. SIP 200 re- INVITE 

32. SIP ACK 
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SIP 202 refer - 

— 5. SIP NOTIFY— 
-8. SIP 200 NOTIF 
—9. SIP INVITE— 
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— 13. SIP ACK — 



(-15. SIP re- INVITE- 

-18. SIP 200 re-INVlTEH 

I 19. SIP ACK 



-21. SIP re- INVITE- 

22. SIP re- INVITE- 

23. SIP 200 re- INVITE 



24. SIP 200 re-INVlTEH 

25. SIP ACK 



-26. SIP ACK- 



-27. SIP re- INV1TE- 



30. SIP 200 re-INVITE-l 

31. SIP ACK 



,„ „ lr . ,„, „ Tr . ^33. SIP re-INVITE- 
-34. SIP re- INVITE- 

-35. SIP 200 re-INVITE>(__3 6 g|p 2QQ ^ 



-38. SIP ACK- 



-^0. SIP NOTIFY— 
-41. SIP 200 notify— 



37. SIP ACK- 

-39. SIP NOTIFY 
42. SIP 200 NOTIF' 



(Audio 2)- 



-(Audio 1, Video)' 



Figure A.12.3A: Controller UE transfers a media from one controllee UE to another controllee UE. 



1-2. SIP REFER request (SIP REFER request from UE-1 to SCC-AS) 

There is an existing session with audio 1 and audio 2 between UE-2 (123.45.67.89) and the remote UE 
(132.54.76.98). The video component is unidirectional from the remote UE to the controllee UE, UE-3 
(123.1 12.67.87). The Controller UE attempts to transfer the audio 1 portion of this session to the controllee UE, 
UE-3. 
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Table A.12.3A-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : scc-as@homel . net SIP/2.0 
Via : 

To: sip : scc-as@homel . net ; tag= 24680 

From: sip : userl_publicl@homel . net ; tag=13579 

Call -ID: Cb0 3a0s09a2sdfglkj 490333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : sip : userl_publicl@homel . net 

Refer- To : <sip :userl_public3@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a765- 
0a0c91e6bf 6body=m%3Daudio%2 00%2 0RTP%2FAVP%2 00%0Dm%3Daudio%2 
49174%2 0RTP%2FAVP%2096%0Dm%3Dvideo%2 01009%2 0RTP%2FAVP%2098%2 099> 

Require: target-dialog 

Target -dialog : cb0 3a0s0 9a2sdf glkj 321576 ; remote- tag=abcdef ; local -tag=1234 56 
Ref erred-By : sip : userl_publicl@homel . net 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5- 

0a0c91ewxyz> ; +g . 3gpp . iut -controller 
Accept: message/sipf rag 
Content-Length: 



3-4. SIP 202 (Accepted) response (from SCC AS to UE-1) 

The SCC-AS sends a SIP 202 (Accepted) response to controller UE-1 as response to the SIP REFER request. 

5-6. SIP NOTIFY request (from SCC AS to UE-1) 

The SCC-AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request 
results. 

Table A.12.3A-2 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 

To : sip :userl_publicl@homel . net ; tag=2468 
From: sip : scc-as@homel . net ; tag=13 5 79 
Call-ID: Cb03a0s09a2sdfglkjl2345 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip : scc-as@homel . net 
Allow: 

Event : refer 

Subscript ion- St ate : active; expires=360 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (from UE-1 AS to SCC-AS) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC-AS. 

9-10. SIP INVITE request (from SCC-AS to UE-3) 

Since the message 1-2 contains a Refer-to header field addressed to UE-3 and the URI paramaters, listing an 
audio line which is not currently supported by another controllee UE than UE-2, the SCC AS realizes the 
procedure is for transferring the media from that controllee UE (UE-2) to controllee UE (UE-3). The SCC-AS 
sends a SIP INVITE request to the controllee UE, UE-3, to transfer the audio media component. The SDP in the 
SIP INVITE request lists the media lines within the collaborative session. In order to avoid UE-3 to start 
sending audio to the remote UE, the SCC-AS adds an a-line set to sendonly in the SDP offer. 
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Table A.12.3A-3 SIP INVITE request (SCC-AS to UE-3) 



INVITE sip : userl_public3@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91eSbf S SIP/2.0 
Via : 

To : sip : userl_public3@homel . net ; 
From: sip : scc-as@homel . net ; tag=12486 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t = 

m=audio 49174 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a= sendonly 
b=RR : 

b=RS : 0m=audio RTP/AVP 
m=video 1009 RTP/AVP 98 99 
a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



11-12. SIP 200 (OK) response (from UE-3 to SCC-AS) 

The controllee UE, UE-3, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 



Table A.12.3A-4 SIP 200 OK request (UE-3 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sip :userl_public3@homel . net ; 


tag = xyzwv 


From: sip : scc-as@homel . net ; tag 


= 12486 


Call-ID: 




CSeq: 




P -Preferred- Identity : 




Contact: sip:userl public3@homel 


. net; gr=urn: uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow : 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123 . 112 .67.87 


s = - 

c=123 . 112 .67.87 




t = 




m=audio 3 02 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 




a=recvonly 




m=audio RTP/AVP 




m=video 13 02 RTP/AVP 98 99 




a=recvonly 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 




a=rtpmap:99 MP4V-ES 





13-14. SIP ACK request(from SCC-AS to UE-3) 

The SCC-AS sends a SIP ACK request to UE-3 to acknowledge. 
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15-16. SIP re-INVITE request (from SCC-AS to controllee UE, UE-2) 

The SCC AS sends a SIP re-INVITE request to controllee UE, UE-2 to put Audio 1 on hold. 

Table A.12.3A-5 SIP INVITE request (SCC-AS to controllee UE, UE-2) 



INVITE sip : userl_public2@home3 . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91eSbf S SIP/2.0 
Via: 

To: sip : userl_public2@homel . net ; 
From: sip : scc-as@homel . net ; tag=12386 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t = 

m=audio 49174 RTP/AVP 96 97 
a=sendonly 
b=RR : 
b=RS : 

m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a=sendonly 
b=RR : 



17-18. SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controllee UE, UE-2 acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 



Table A.12.3A-6 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via : 




To: sip:userl public2@homel.net; 


tag = xyzwv 


From: sip : scc-as@homel . net ; tag 


= 12486 


Call-ID: 




CSeq: 




P -Preferred- Identity : 




Contact: sip:userl public2@homel 


. net ;gr=urn :uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow : 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123 .45.67.89 


s = - 

c=IN IP4 123.45.67.89 




t = 




m=audio 32324 RTP/AVP 96 97 




a=recvonly 




m=audio 34002 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 




a=recvonly 





19-20. SIP ACK request (from SCC-AS to UE-2) 

The SCC-AS send a SIP ACK request to UE-2 to acknowledge. 
21-22. SIP re-INVITE request (from SCC-AS to remote UE) 

The SCC-AS sends a SIP re-INVITE request to the remote UE, UE-4. 
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Table A.12.3A-7 SIP INVITE request (SCC-AS to remote UE, UE-4) 



INVITE sip : user2_publicl@home3 . net ; SIP/2 . 
Via : 

To : sip : user2_publicl@home2 . net ; tag=66666 
From: sip : scc-as@homel . net ; tag=33333 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91ewxyz 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 
t = 

m=audio 3002 RTP/AVP 96 97 
c= IN IP4 123.112.67.87 
a=rtpmap:0 PCMU/8000 
m=audio 34 02 RTP/AVP 96 97 
C=IN IP4 123.45.67.89 
A=rtpmap:0 PCMU/8000 
m=video 1302 RTP/AVP 98 99 
c= IN IP4 123.112.67.87 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=recvonly 



23-24. SIP 200 (OK) response (from remote UE, UE-4 to SCC-AS) 

The remote UE acknowledges the SIP re-INVITE request by sending a SIP 200 (OK) response to the SCC-AS. 

Table A.12.3A-8 SIP 200 OK request (UE-4 to SCC-AS) 



SIP/2.0 200 OK 

Via : 

To: 

From: 

Call-ID: 

CSeq: 

P- Asserted- Identity : 

Contact : sip : user2_publicl@home2 . net ; 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c= IN IP4 132.54.76.98 
t = 

m=audio 49174 RTP/AVP 96 97 
b=AS : 25 . 4 
a=rtpmap:96 AMR 

a=f mtp : 96mode- set=0 ,2,5,7; mode -change -per iod=2 
a=rtpmap:97 telephone-event 
a=maxptime : 2 

m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
m=video 1009 RTP/AVP 98 99 
a=sendonly 
b=AS : 75 

a=rtpmap:98 H263 
a=fmtp:98 H263 

a=fmtp:98 prof ile-level-id=0 
a=rtpmap:99 MP4V-ES 
a=sendonly 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 160 ETSI TS 124 237 V9.4.0 (2010-10) 



25-26. SIP ACK request (from SCC-AS to remote UE) 

The SCC-AS sends a SIP ACK request to the remote UE. 
27-28. SIP re-INVITE request (from SCC-AS to controllee UE, UE-2) 

The SCC-AS sends a SIP re-INVITE request to UE-2 to remove the audio 1 media component. 

Table A.12.3A-9 SIP re-INVITE request (SCC-AS to UE-2) 



INVITE sip : userl_public2@home3 . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 SIP/2.0 
Via: 

To: sip : userl_public2@homel . net ; 
From: sip : scc-as@homel . net ; tag=12386 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : 

Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 132.54.76.98 
s = - 

c=IN IP4 132.54.76.98 
t = 

m=audio RTP/AVP 
m=audio 44552 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 



29-30, SIP 200 (OK) response (from UE-2 to SCC-AS) 

The controllee UE, UE-2, acknowledges the SIP INVITE request by sending a SIP 200 (OK) response to the 
SCC-AS. 



Table A.12.3A-10 SIP 200 (OK) response (UE-2 to SCC-AS) 



SIP/2.0 200 OK 




Via: 




To: sip :userl_public2@homel . net ; 


tag = xyzwv 


From: sip : scc-as@homel . net ; tag 


= 12486 


Call-ID: 




CSeq: 




P -Preferred- Identity : 




Contact: sip:userl public2@homel 


. net ;gr=urn :uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 1027933615 1027933615 IN IP4 


123 .45.67.89 


s = - 

c=IN IP4 123.45.67.89 




t = 




m=audio RTP/AVP 




m=audio 34 02 RTP/AVP 96 97 




a=rtpmap:0 PCMU/8000 





31-32. SIP ACK request (from SCC-AS to UE-2) 

The SCC-AS sends a SIP ACK request to UE-2 to acknowledge. 
33-34. SIP re-INVITE request (from SCC-AS to controllee UE, UE-3) 

The SCC-AS sends a SIP re-INVITE request to UE-3 to activate the audio 1 media component. 

NOTE: The SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 
was generated by the SCC AS due to third party call cotrol to allow sending this SIP re-INVITE request. 
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Table A.12.3A-11 SIP re-INVITE request (SCC-AS to UE-3) 



INVITE sip : userl_public3@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91eSbf 6 SIP/2.0 
Via : 

To : sip : userl_public3@homel . net ; 
From: sip : scc-as@homel . net ; tag=12486 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Ref erred-By : sip : userl_publicl@homel . net 
Contact : 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=IN IP4 123 . 112 .67.87 
t = 

m=audio 49174 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
a= sendrecv 
m=audio RTP/AVP 
m=video 1009 RTP/AVP 98 99 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

a=sendonly 



35-36. SIP 200 (OK) response (from controllee UE, UE-3 to SCC-AS) 

Controllee UE, UE-3 sends a SIP 200 (OK) response to the SCC AS. 
37-38. SIP ACK request (from SCC-AS to UE-3) 

The SCC-AS sends a SIP ACK request to the remote UE. 

39-40. SIP NOTIFY request (from SCC-AS to controller UE, UE-1) 

The SCC AS sends a SIP NOTIFY request containing SDP of the SIP 200 (OK) response received from the 
controllee UE, UE-3. 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 162 ETSI TS 124 237 V9.4.0 (2010-10) 

Table A.12.3A-12 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip : userl_publicl@homel . net ; 
Via : 

To: sip : userl_publicl@homel . net ; tag=13579 
From: sip : scc-as@homel . net ; tag= 24680 
Call-ID: 
CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Content-Type: message/sipf rag ; version=2 . ; 
Content-Length: (...) 

SIP/2.0 200 OK 

To: sip : userl_public3@homel . net ; tag = xyzwv 
From: sip : scc-as@homel . net ; tag = 12486 
Call-ID: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 

c=123 . 112 .67.87 
t = 

m=audio 3002 RTP/AVP 96 97 
a=rtpmap:0 PCMU/8000 
m=audio RTP/AVP 
m=video 1302 RTP/AVP 98 99 
a=recvonly 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



41-42. SIP 200 (OK) response (from controller UE to SCC-AS) 

The controller UE acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC-AS. 



A. 13 Signalling flows for release of collaborative session 
for inter-UE transfer 

A. 13.1 Introduction 

The signalling flows for release of Collaborative Session demonstrate how the session is released by the Controller UE 
or by the remote party UE. The following signalling flows are included: 

- subclause A. 13.2 shows an example where the Controller UE initiates the release of a Collaborative Session. It 
demonstrates how the service control signalling and media path between the Controller UE and remote UE and 
the media path between the Controllee UE and the remote UE are released as a result of the session release; and 

- subclause A. 13. 3 shows an example where the remote UE initiates the release of a Collaborative Session. 



A. 13.2 Controller UE releases collaborative session 

In this example, session release is initiated by the Controller UE (UE 1), which is involved in the Collaborative Session 
with UE 2 and the remote UE (UE 3). The SCC AS ensures that all Controllee UEs involved in the Collaborative 
Session receive a request for session release in order to completely release the session ongoing with the remote UE. 
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HPLMN of the originating UE 
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1 . Collaborative Session involving UE 1 and UE 2 in a dialog with UE 3. UE 1 is the Controller UE and UE 2 is the Controle 

end UE. 



UE. UE 3 is the remote 



Service control signalling— 

Media path between UE1 and UE 3- 



-2. SIP BYE- 



— 11. SIP BYE 

-12. SIP 200 (OK)- 



-15. SIP 200 (OK)- 



■Media path between UE2 and UE 3- 



-3. SIP BYE- 
-4. SIP BYE- 



-5. SIP BYE- 



-8. SIP 200 (OK)- 



-9. SIP 200 (OK)- 
—10. SIP BYE — 



-13. SIP 200 (OK)- 
-14. SIP 200 (OK)- 



— 6. SIP BYE — 
-7. SIP 200 (OK)- 



Figure A.1 3.2-1 : Release of Collaborative Session initiated by Controller UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. Collaborative Session currently exists in a dialog with UE 3 

A Collaborative Session involving UE 1 and UE 2 exists in a dialog with UE 3. Media paths exist between UE 1 
and UE 3 and between UE 2 and UE 3. In this scenario, UE 1 is the Controller UE in the Collaborative Session 
and thus maintains service control signalling with the SCC AS. 

2-3. SIP BYE request (UE 1 to SCC AS via intermediate IM CN subsystem entities) 

UE 1, acting as the Controller UE, initiates session release by sending a SIP BYE request towards the SCC AS. 
There is no Inter UE transfer specific content in the SIP BYE request. 

4-6. SIP BYE request (SCC AS to UE 3 via intermediate IM CN subsystem entities) 

The SCC AS routes the SIP BYE request to UE 3 indicating to the remote UE that the Controller UE requests 
that the session is to be released. 

7-9. SIP 200 (OK) response (UE 3 to SCC AS via intermediate IM CN subsystem entities) 

UE 3 responds to the received SIP BYE request with a SIP 200 (OK) response. 

10-11. SIP BYE request (SCC AS to UE 2 via intermediate IM CN subsystem entities) 

The SCC AS, acting as a routing B2BUA, sends a SIP BYE request towards UE 2 to release the dialog it is 
involved in with UE 3 via the Collaborative Session. There is no Inter UE transfer specific content in the SIP 
BYE request. 
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NOTE 1: The SIP BYE request to UE 2 (step 10) can occur in parallel with the SIP BYE request to UE 3 (step 4). 

Alternatively, the SCC AS can send the SIP BYE request to UE 2 prior to sending the SIP BYE request to 
UE 3. 

12-13. SIP 200 (OK) response (UE 2 to SCC AS via intermediate IM CN subsystem entities) 

UE 2 responds to the received SIP BYE request with a SIP 200 (OK) response. 

14-15 SIP 200 (OK) response (SCC AS to UE 1 via intermediate IM CN subsystem entities) 

Upon receiving SIP 200 (OK) responses from UE 2 and UE 3, the SCC AS responds to the SIP BYE request 
from UE 1 with a SIP 200 (OK) response. 

NOTE 2: The SIP 200 (OK) response in step 14 can be sent earlier by the SCC AS in response to the SIP BYE 

request received from UE l(step 3). For example, the SCC AS can send the SIP 200 (OK) response to UE 
1 after receiving the SIP 200 (OK) response from UE 3 (step 9). 

A. 13.3 Remote UE releases collaborative session 

In this example, session release is initiated by the remote UE (UE 3). UE 1 and UE 2 are included in a Collaborative 
Session with the remote UE. The SCC AS ensures that all Controllee UEs involved in the Collaborative Session receive 
a request for session release in order to completely release the ongoing session. 
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entitities 
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1 . Collaborative Session involving UE 1 and UE 2 in a dialog with UE 3. UE 1 is the Controller UE and UE 2 is the Controlee UE. UE 3 is the remote 

end UE. 



Service control signalling— 

Media path between UE1 and UE 3- 



-6. SIP BYE- 



-8. SIP BYE- 



-9. SIP 200 (OK)- 



-11. SIP 200 (OK)- 



■Media path between UE2 and UE 3- 



-3. SIP BYE- 



-4. SIP BYE- 



-5. SIP BYE- 



-7. SIP BYE- 



-10. SIP 200 (OK)- 



-12. SIP 200 (OK)- 



-13. SIP 200 (OK) — 
14. SIP 200 (OK)- 



-2. SIP BYE- 



-15. SIP 200 (OK)- 

Figure A.13.3-1 : Release of Collaborative Session initiated by remote UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
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1. Collaborative Session currently exists in a dialog with UE 3 

A Collaborative Session involving UE 1 and UE 2 exists in a dialog with UE 3. Media paths exist between UE 1 
and UE 3 and between UE 2 and UE 3. In this scenario, UE 1 is the Controller UE in the Collaborative Session 
and thus maintains service control signalling with the SCC AS. 

2-4. SIP BYE request (UE 3 to SCC AS via intermediate IM CN subsystem entities) 

The remote UE, UE 3, initiates session release by sending a SIP BYE request towards the Controller UE via the 
SCC AS serving the Controller UE. There is no Inter UE transfer specific content in the SIP BYE request. 

5-6. SIP BYE request (SCC AS to UE 1 via intermediate IM CN subsystem entities) 

The SCC AS routes the SIP BYE request to UE 1, indicating to UE 1 that the remote UE requests that the 
session is to be released. 

7-8. SIP BYE request (SCC AS to UE 2 via intermediate IM CN subsystem entities) 

The SCC AS, acting as a routing B2BUA sends a SIP BYE request to UE 2 to release the dialog it is involved in 
with UE 3 via the Collaborative Session. There is no Inter UE transfer specific content in the SIP BYE request. 

NOTE 1: Step 7 can occur in parallel with step 5. Alternatively, step 7 can occur prior to step 5. The order in which 
the SCC AS sends the SIP BYE requests is not considered to be important. 

9-10. SIP 200 (OK) response (UE 1 to SCC AS via intermediate IM CN subsystems entities) 

UE 1 responds to the received SIP BYE request with a SIP 200 (OK) response. 
NOTE 2: Step 9 can occur immediately after UE1 has received the SIP BYE request in step 6. 
11-12. SIP 200 (OK) response (UE 2 to SCC AS via intermediate IM CN subsystems entities) 

UE 2 responds to the received SIP BYE request with a SIP 200 (OK) response. 

13-15. SIP 200 (OK) response (SCC AS to UE 3 via intermediate IM CN subsystem entities) 

Upon receiving SIP 200 (OK) responses from UE 1 and UE 2, the SCC AS responds to the SIP BYE request 
from UE 3 with a SIP 200 (OK) response. 

NOTE 3: Step 13 can occur after the SCC AS has received the SIP BYE request step 4 since it is not necessary to 
wait for SIP BYE requests to UE1 and UE2. 



A.14 Signalling flows for media adding/deleting within 
collaborative session for inter-UE transfer 

A. 14.1 Introduction 

This subclause shows signalling flows for adding and releasing of mediacomponent by the controller UE. Four different 
scenarios are considered in this subclause: 

scenario where the controller UE adds a new media component on a controllee UE. The procedures in this 
subclause are the same as the procedures described in subclause A.l 1.2 with the exception that upon the receipt 
of a SIP REFER request from the controller UE, the SCC AS generates a SIP re-INVITE request within the 
dialog to the controllee UE instead of a SIP INVITE request; 

- scenario where the controller UE releases a media component from the controller UE, see subclause A. 14.2.1; 

- scenario where the controller UE releases a media component from the controllee UE, see subclause A. 14.2.2.1; 
and 

scenario where the controller UE releases a media component from the controllee UE and that causes the 
termination of the collaborative session, see subclause A. 14.2.2.2. 
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A. 14.2 Controller UE releases media 



A.1 4.2.1 Controller UE releases media flow on controller UE 




1. re-INVITE 
Media-A=0 ' 



10. 200 (OK) 
-c= Remote UE- 
Media-A=0 



11.ACK- 



2. re-INVITE_ 
Media-A=0 

3. re-INVITE 
c=UE-1 

- Media-A=0 - 
c=UE-2 
Media-B 



6. 200 OK 
c=UE-1 
-Media-A=0 
c=UE-2 
Media-B 

— 7.ACK — 



4. re-INVITE 

c=UE-1 
- Media-A=0 - 
c=UE-2 
Media-B 
I 

5. 200 OK 
c=UE-1 
-Media-A=0— 
c=UE-2 
Media-B 



-8.ACK- 



9. 200 (OK) 
-c=Remote UE- 
Media-A=0 



-12.ACK- 



■Collabarative session control 1 

^ Media-B between UE-2 and Remote UE- 



Figure A.1 4.2.1 : Controller UE releases media flow on controller UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with voice (Media A) and UE-2 with video (Media B) media flows. Subsequently, the UE-1 (controller 
UE) removes the media A flow that is active on the remote UE. 

1. SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities)- see example in table A.14.2.1-1 

UE-1 sends a SIP re-INVITE request towards the remote UE indicating Media A is to be removed in the SDP 
offer. 
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Table A.14.2.1-1: SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE <sip :userR_public@homel . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91e6bf 6 > SIP/2.0 
Via : SIP/2 . 0/UDP [3 33 3 : : eee : f f f : aaa :bbb] : 13 5 7 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . visitedl . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> 

P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 

c=8642; port-s=7531 
Contact : <sip : userl_public@homel . net > ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a765- 

0a0c6 7t 6br4 > ; +g . 3gpp . iut -controller 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 3 33 3 : : aaa : bbb : ccc : ddd 
s = - 
t = 

m=audio RTP/AVP 97 

c=IN IP6 3333 :: aaa :bbb : ccc :ddd 

a=rtpmap:97 PCMU/8000 

m=video RTP/AVP 98 

c=IN IP6 4444 :: aaa : bbb : ccc : ddd 

a=rtpmap:98 MPV/90000 



2. SIP re-INVITE request 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the SCC AS according to 
standard IMS procedure. 

3. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.14.2.1-3 

The SCC AS sends a SIP re-INVITE request with all the media information at the remote UE, sets the port 
number for media A to 0, and forwards it towards the remote UE through the intermediate IM CN subsystem 
entities. 
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Table A.14.2.1-3: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip :userR_public2@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91eSbf 6> IP/2.0 
Via: SIP/2. 0/UDP sccasl .homel . net ;branch=z9hG4bK240f 34 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> 
P-Access-Network-Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 
From : 
To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 

c=8S42; port-s=7531 
Contact : 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Length: (...) 
v=0 

o = - 2987933615 2987933615 IN IP6 3333 : : aaa : bbb : ccc : ddd 
s = - 

t=o o 

m=audio RTP/AVP 97 

c=IN IP6 3333 :: aaa :bbb : ccc :ddd 

a=rtpmap:97 MPV/90000 

m=video 8888 RTP/AVP 98 

c=IN IP6 4444 :: aaa : bbb : ccc : ddd 

a=rtpmap:98 MPV/90000 



4. SIP re-INVITE request 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the remote UE according to 
standard IMS procedure. 

5. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.1-5 

The remote UE sends a SIP 200 (OK) response with an SDP answer. 

Table A.14.2.1-5: SIP 200 (OK) response (remote UE to IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=dahtadf z4radgs . 12 , SIP/2. 0/UDP 
scscf 2 .homel .net ; branch=hsdf ldf 343 . 12 , SIP/2 . 0/UDP 
scscf 1 .homel .net ;branch=hsdf ldf 56322cc . 13 , SIP/2 . 0/UDP 
sccasl . homel . net ; branch=z9hG4bKnas34r2 . 2 1 

From: 

To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = - 

c=IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio RTP/AVP 97 
a=rtpmap:97 MPV/90000 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 
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6. SIP 200 (OK) response 

7. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS sends a SIP ACK request to the remote UE through the intermediate IM CN subsystem entities. 

8. SIP ACK request (intermediate IM CN subsystem entities to remote UE) 

9-10. SIP 200 (OK) response (SCC AS to UE-1 through intermediate IM CN subsystem entities) 

The SCC AS sends a SIP 200 (OK) response with an SDP answer indicating that Media-A has been removed 
11-12. SIP ACK request (controller UE to SCC AS) 
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A. 14.2.2 Controller UE releases media flow on controllee UE 
A. 14.2.2.1 Controller UE removes media at the controllee UE 
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NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

Figure A.14.2.2.1 Controller UE remove media at the controllee UE 

1-2. SIP REFER request (controller UE to intermediate IM CN subsystem entities) - see example in 
table A. 14.2. 1-1 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia 
session on his device UE-1 with a voice (Media A) and UE-2(Controllee UE) with a video (Media B) media 
flows and a voice (Media C) media flow. The controller UE wants to remove the video media (Media B) 
component on the controllee UE. 

Table A.1 4.2.2.1-1 SIP REFER request (UE-1 to SCC AS) 



REFER sip : interUEtransf er@sccasl . homel . net SIP/2.0 
Via: 

To : sip : interUEtransf er@sccasl . homel . net 
From: sip :userl_publicl@homel . net ; tag =13579 
Call -ID: Cb03a0s09a2sdfglkj 490333 
CSeq: 93809824 REFER 
Max-Forwards: 70 

P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net > 

Refer- To : <sip : user2_public2@home2 . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a762 - 0a0c91e6bf 6 ? 

body=m%3Daudio%2 00%2 0RTP%2FAVP%2 097%0Dm%3Daudio%2 04568%2 0RTP%2FAVP%2 097%0Dm%3Dvideo%2 00%2 0R 

TP%2FAVP%2 098> 
Require: target-dialog 

Target -dialog: cb03a0s0 9a2sdf glkj 13 5 79 ; to- tag=abcdef ; f rom-tag=12 34 5 6 
Ref erred-By : sip : userl_publicl@homel . net 

Contact : <sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91ewxyz> ; +g . 3gpp . iut -controller 
Allow : 

Accept: message/sipf rag 
Content-Length: 

3-4. SIP 202 (Accepted) response 

The SCC- AS sends a SIP 202 (Accepted) response to the controller UE-1 as response to the SIP REFER request. 

5-6. SIP NOTIFY request (SCC AS to UE-1 through intermediate IM CN subsystem entities)-see example 
in table A.14.2.1-5 

The SCC- AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request 
results. 

Table A.1 4.2.2.1 -5 SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91ewxyz SIP/2.0 
Via: 

To : sip :userl_publicl@homel . net ; tag=13579 

From : sip : interUEtransf er@sccasl . homel . net ; tag=22 55 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- St ate : active; expires=36 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (UE-1 to SCC-AS through intermediate IM CN subsystem entities) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the 
SCC AS. 

9-10. SIP UPDATE request (SCC AS to remote UE through intermediate IM CN subsystem entities) - see 
example in table A.14.2.2.2-9. 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 1 73 ETSI TS 1 24 237 V9.4.0 (201 0-1 0) 

The SCC AS prepares the removal of the media component received by the controllee UE-2 and sent by the 
remote UE. 



Table A.14.2.2.2-9: SIP UPDATE request (SCC AS to remote UE through intermediate IM CN 

subsystem entities) 



UPDATE sip:UserR publicl@homel . net ; gr=urn :uuid 


f 81d4f ae-7dec- 


Ild0-a762 


-00a0c91e6bf 6 SIP/2.0 


Via : 








To : 








From : 








Call-ID: 








Cseq : 








Contact: <sip: userl publicshomel . net> ; gr=urn 


uuid: f 81d4fae- 


7dec-lld0 


-a765-00a0c67t6br4> 


Allow: 








Content-Type: application/sdp 








Content-Length: (...) 








v=0 








o = - 2987933615 2987933615 IN IP6 3333 : : aaa : bbb 


ccc : ddd 






s = - 
t = 








m=audio 6666 RTP/AVP 97 








c=IN IP6 3333 :: aaa: bbb: ccc:ddd 








a=rtpmap:97 PCMU/8000 








m=video 6668 RTP/AVP 98 








a=sendonly 








b=RR: 








b=RS : 








c=145 .23.77.88 








b=AS : 75 








a=rtpmap:98 H263 








a=fmtp:98 prof ile-level-id=0 









11-12. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.2-11. 

Remote UE send a SIP 200 (OK) response with SDP answer. 
Table A.14.2.2.2-11 SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: 

To: 

From: 

Call-ID: 

Cseq : 

Contact : <sip : userR_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a762 - 0a0c91e6bf 6 > 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 5 5 5 5 : : aaa : bbb : : ccc : ddd 
s = - 
t = 

m=audio 4444 RTP/AVP 97 

c = IN IP6 5555: : aaa: bbb: : ccc: ddd 

a=rtpmap:9777 PCMU/8000 

m=video 6666 RTP/AVP 98 

a=recvonly 

b=RR : 

b=RS : 

c=145.23.77.88 
b=AS : 75 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 



13. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.1-13 
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The SCC AS sends a SIP re-INVITE request towards the Controllee UE (UE-2). 

Table A.1 4.2.2.1 -13 SIP re-INVITE request (SCC-AS to IM CN subsystem entities) 



INVITE sip :user2_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a7S5-00a0c91e6bf 6 SIP/2.0 

Via: 

Route : 

To : sip : user2_publicl@homel . net ; abedef 

From: sip :user3_public3@home3 . net ; tag=1234 56 

Call-ID: 

CSeq: 

Max- Forwards : 
Require : 

Ref erred-By : sip : userl_publicl@homel . net 

Contact : sip : user3_public3@home3 . net ;gr=urn : uuid : f 81d4f ae-17oct-llal-a678-0054c91eabcd 
Allow: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 
t = 

m=audio RTP/AVP 97 
m=audio 4568 RTP/AVP 97 
c=123 . 112 .67.87 
b=AS : 75 

a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 
a=sendonly 



14. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2) 

15-16. SIP 200 (OK) response (UE-2 to SCC AS through intermediate IM CN subsystem entities) 

17-18. SIP ACK request (from SCC-AS to UE-2) 

19. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2-19 

The SCC AS sends a SIP re-INVITE request with all the media information at the remote UE, set the port 
number for media B to 0, and forwards it to the remote UE through the intermediate IM CN subsystem entities. 
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Table A.14.2.2.1-19: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userR_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-0 0a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r2 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip :userl_publicl@homel . net> 
Privacy: none 
From: 
To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip: userl_public@homel . net> ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c67t6br4 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp 
Content-Length: ( . . ) 

v=0 

o = - 2987933615 2987933615 IN IP6 3 3 3 3 : : aaa : bbb : ccc : ddd 
s = - 

c = IN IP6 3333 : : aaa: bbb: ccc: ddd 
t = 

m=audio 6666 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=audio 4567 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



20. SIP re-INVITE request (intermediate IM CN subsystem entities to remote UE) 

21. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.1-21 

The remote UE sends a SIP 200 (OK) response with an SDP answer. 
Table A.1 4.2.2.1 -21 SIP 200 (OK) (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=343asdf aredf atz . 12 , SIP/2. 0/UDP 

scscf 2 .homel .net ;branch=f sc35avhthaz4 .22 , SIP/2 . 0/UDP 

scscf 1 .homel .net ;branch=f sc35avhthaz4 . 12 , SIP/2 . 0/UDP 

sccasl . homel . net ; branch=z9hG4bKnas34r2 . 14 
From : 
To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5555 :: aaa : bbb :: ccc : ddd 
s = - 

c = IN IP6 5555: : aaa: bbb: : ccc: ddd 
t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap:9777 PCMU/8000 
m=audio 4545 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



22. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
23-24. SIP ACK request (SCC AS to remote UE) 

25-26. SIP re-INVITE request (SCC AS to UE-2 through intermediate IM CN subsystem entities) 
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SCC AS sends a SIP re-INVITE request towards Controllee UE (UE-2). 

NOTE: The SIP re-INVITE request is triggered by the SIP REFER request. The previous SIP INVITE request 
was generated by the SCC AS due to third party call cotrol to allow sending this SIP re-INVITE request. 

Table A.1 4.2.2.1 -25 SIP re-INVITE request (SCC-AS to UE-2) 



INVITE sip :user2_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 
Route : 

To : sip : user2_publicl@homel . net ; abedef 

From : sip : user3_public3@home3 . net ; tag=1234 56 

Call-ID: 

CSeq: 

Max- Forwards : 

Contact : sip : user3_public3@home3 . net ; gr=urn : uuid : f 81d4f ae- 17oct- llal-a678 - 0054c91eabcd 
Allow : 

Ref erred-By : sip : userl_publicl@homel . net 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 1027933615 1027933615 IN IP4 123.112.67.87 
s = - 
t = 

m=audio RTP/AVP 97 
m=audio 4568 RTP/AVP 97 
c=123 . 112 .67.87 
b=AS : 75 

a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 



27-28. SIP 200 (OK) response (UE-2 to SCC AS through intermediate IM CN subsystem entities) 

29-30. SIP NOTIFY request (SCC-AS to UE-l)-see example table A.14.2.2.1-21 

The SCC AS sends a SIP NOTIFY request to the controller UE, UE-1 to inform about the success status of the 
inter-UE transfer. 

Table A.1 4.2-2.1 -29 SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-0 0a0c91ewxyz SIP/2.0 
Via: 

To: sip :userl_publicl@homel . net ; tag = 13579 

From : sip : interUEtransf erOsccasl . homel . net ; tag=22 55 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 

v=0 
s = - 

m=audio 3434 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 
a=sendonly 



31-32. SIP 200 OK response (UE-1 to SCC AS) 
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The controller UE,UE-1 acknowledges the SIP NOTIFY request by sending a SIP 200 OK response to the SCC 
AS. 
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A. 14.2.2.2 Controller UE remove the controllee UE from the collaborative session 
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Figure A.14.2.2.2:Controller UE remove the controllee UE from the collaborative session 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1-2. SIP REFER request (controller UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.2-1 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia 
session on his device UE-1 with a voice (Media A) and UE-2(Controllee UE) with a video (Media B) media 
flow. The controller UE wants to remove the controllee UE from the collaborative session. 

Table A.14.2.2.2-1 SIP REFER request (UE-1 to SCC-AS) 



REFER sip : interUEtransf er@sccasl . homel . net SIP/2.0 
Via: 

To : sip : interUEtransf er@sccasl . homel . net 

From: sip : userl_publicl@homel . net ; tag = 13579 

Call- ID: Cb03a0s09a2sdfglkj49033 3 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P -Preferred- Identity : 

Refer- To : <sip :user2_public2@home2 . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a762 - 

00a0c91e6bf 6 ; method=BYE> 
Require: target-dialog 

Target-dialog: cb03a0s09a2sdf glkj 13579 ; to-tag=abcdef ; f rom-tag=123456 
Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- Ild0-a76 5- 

00a0c91ewxyz> ; +g . 3gpp . iut-controller 
Allow: 

Ref erred-By : sip : userl_publicl@homel . net 
Accept : 
Content-Type : 
Content-Length : 



3-4. SIP 202 (Accepted) response 

The SCC AS sends a SIP 202 (Accepted) response to the controller UE-1 as response to the SIP REFER request. 

5-6. SIP NOTIFY request (SCC AS to UE-1 through intermediate IM CN subsystem entities) - see example 
in table A.14.2.2.2-5 

The SCC AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request 
results. 

Table A.14.2.2.2-5 SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY 
Via: 

To : sip :userl_publicl@homel . net ; tag=13579 

From : sip : interUEtransf er@sccasl . homel . net ; tag=22 5 5 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow: 

Event : refer 

Subscript ion- St ate : active; expires=36 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



7-8. SIP 200 (OK) response (UE-1 to SCC AS through intermediate IM CN subsystem entities) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) to the SCC AS. 
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9-10. SIP UPDATE request (SCC AS to remote UE through intermediate IM CN subsystem entities) - see 
example in table A.14.2.2.2-9. 

The SCC AS prepares the removal of the controllee UE-2 from the collaborative session by stopping the media 
received by the controllee UE-2 and sent by the remote UE. 



Table A.14.2.2.2-9: SIP UPDATE request (SCC AS to Remote UE through intermediate IM CN 

subsystem entities) 



UPDATE sip:UserR publiclOhomel . net ; gr=urn :uuid 


f 81d4f ae-7dec- 


lldO 


-a762 


-00a0c91e6bf 6 SIP/2.0 


Via : 










To: 










From : 










Call-ID : 










Cseq : 










Contact: <sip: userl_public@homel . net> ; gr=urn 


uuid: f 81d4f ae- 


7dec 


-lldO 


-a765-0 0a0c67t6br4> 


Allow : 










Content - Type : application/sdp 










Content-Length: (...) 










v=0 










o = - 2987933615 2987933615 IN IP6 3333 : : aaa : bbb 


ccc : ddd 








s=- 
t = 










m=audio 6666 RTP/AVP 97 










c = IN IP6 3333: : aaa: bbb: ccc:ddd 










a=rtpmap:97 PCMU/8000 










m=video 6668 RTP/AVP 98 










a=sendonly 










b=RR : 










b=RS : 










c=145 .23 . 77 . 88 










b=AS : 75 










a=rtpmap:98 H263 










a=fmtp:98 prof ile-level-id=0 











11-12. SIP 200 (OK) response (Remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.2-11. 

Remote UE sends a SIP 200 (OK) response with SDP answer. 
Table A.14.2.2.2-11 SIP 200 (OK) response (Remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 




Via : 




To: 




From : 




Call-ID: 




Cseq : 




Contact: <sip:userR publiclOhomel . net ; gr=urn : uuid : fi 


Sld4fae-7dec-lld0-a762-0 0a0c91e6bf 6> 


Allow: 




Content-Type: application/sdp 




Content-Length: (...) 




v=0 




o=- 2987933300 2987933300 IN IP6 5555 :: aaa : bbb :: ccc 


ddd 


s = - 
t = 




m=audio 4444 RTP/AVP 97 




c=IN IP6 5555 :: aaa : bbb :: ccc : ddd 




a=rtpmap : 9777 PCMU/8000 




m=video 6666 RTP/AVP 98 




a=recvonly 




b=RR : 




b=RS : 




c=145 .23.77.88 




b=AS : 75 




a=rtpmap:98 H263 




a=fmtp:98 prof ile-level-id=0 
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13-14. SIP BYE request (SCC AS to UE-2 through intermediate IM CN subsystem entities) 

The SCC AS sends a SIP BYE request towards the controllee UE (UE-2). 

15-16. SIP 200 (OK) response (UE-2 to SCC AS through intermediate IM CN subsystem entities) 

17. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.2-17 

The SCC AS sends a SIP re-INVITE request with all the media information at the remote UE, set the port 
number for media B to 0, and forwards it to the remote UE through the intermediate IM CN subsystem entities. 

Table A.14.2.2.2-17: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userR_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-0 0a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r2 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : userl_publicl@homel . net> 
P-Access-Network-Inf o : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 
From : 
To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 
c=8G42; port-s=7531 

Contact: <sip: userl_public@homel . net> ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c67t6br4 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Length: 

v=0 

o = - 2987933615 2987933615 IN IP6 3 3 3 3 : : aaa : bbb : ccc : ddd 
s = - 

c = IN IP6 3333 : : aaa: bbb: ccc: ddd 
t = 

m=audio 6666 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



18. SIP re-INVITE request (intermediate IM CN subsystem entities to remote UE) 

19. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.2.2.2-19 

The remote UE sends a SIP 200 (OK) response with SDP answer. 
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Table A.1 4.2.2.2-1 9 SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=343asdf aredf atz . 12 , SIP/2. 0/UDP 

scscf 2 .homel .net ;branch=f sc35avhthaz4 .22 , SIP/2 . 0/UDP 

scscf 1 .homel .net ;branch=f sc35avhthaz4 . 12 , SIP/2 . 0/UDP 

sccasl . homel . net ; branch=z9hG4bKnas34r2 . 14 
From: 
To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 5555 : : aaa : bbb : : ccc : ddd 
s = - 

c=IN IP6 5555 :: aaa : bbb :: ccc : ddd 
t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap : 9777 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90000 



20. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
21-22. SIP ACK request (SCC AS to remote party) 

23-24. SIP NOTIFY request (SCC-AS to UE-l)-see example in table A.14.2.2.2-25 

The SCC-AS sends a SIP NOTIFY request to the controller UE, UE-1 to inform about the success status of the 
inter-UE transfer. 

Table A.1 4.2.2.2-23 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY 
Via: 

To: sip :userl_publicl@homel . net ; tag = 13579 

From : sip : interUEtransf erOsccasl . homel . net ; tag=22 55 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact: sip: scc-as@homel.net 
Allow : 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type: message/sipf rag ; version=2 . 
Content-Length: (...) 

SIP/2.0 200 OK 



25-26. SIP 200 OK response (UE-1 to SCC-AS) 

The controller UE,UE-1 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC 
AS. 
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A. 14.4 Controllee UE releases media 



UE-1 




UE-2 






Intermediate 
IM CN entities 



SCC 
AS 



-Collabarative session control 1 

Media-A between UE-1 and Remote UE' 



i/ledia-B between UE-2 and Remote UE- 



1. re-INVITE- 



14. 200 (OK)- 
—15. ACK — 



-2. re-INVITE- 
-3, re-INVITE- 



-6, 200 (OK)- 
— 7, ACK — 



9. re-INVITE 

c=UE-1 
- Media-A - 
c=UE-2 
Media-B=0 



10. re-INVITE 
c=UE-1 
— Media-A — 
c=UE-2 
Media-B=0 
11.200 (OK) 
_c= Remote Party_ 
Media-A 
Media-B=0 



12.200 (OK) 
_c= Remote Party 
Media-A 
Media-B=0 

-13. 200 (OK)— 



-16. ACK- 
-17. ACK- 



-18. ACK- 



Collabarative session control- 

i 



Media-A between UE-1 and Remote UE- 



Remote 
UE 



Figure A.14.4: Controllee UE releases media 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

It is assumed that UE-1 is controller UE having collaborative session control, a user has a multimedia session on his 
device UE-1 with voice (Media A) and UE-2(Controllee UE) video (Media B) media flows. Subsequently, the UE-2 
(Controllee UE) removes the media B flow that is active on the remote UE. 

1-2. SIP re-INVITE request (UE-2 to SCC AS through IM CN subsystem entities) 

A UE-2 wants to release media B active on the remote UE. For this purpose the UE-2 sends a SIP re-INVITE 
request to the SCC AS through the IM CN subsystem entities. 

3. SIP re-INVITE request (from SCC-AS to intermediate IM CN subsystem entities) - see example in 
table A.14.4-3 

The SCC AS sends SIP re-INVITE request to controller UE, UE-1 to inform that the controllee UE wants to 
release one media, and SCC AS would like to add this media back to the controller UE. 
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Table A.14.4-3: SIP re-INVITE request (SCC AS to controller UE) 



INVITE <sip :userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-0 0a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r2 . 12 
Max-Forwards: 70 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe" <sip : user3_public3@home3 . net > 
Privacy: none 
From: 
To : 

Call-ID: 

Cseq: 127 INVITE 
Require : 

Contact: <sip: user3_public3@home3 . net> ; gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c67t6br4> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE , SUBSCRIBE, NOTIFY 
Content-type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 3 3 3 3 : : aaa : bbb : ccc : ddd 

s=- 

t = 

m=audio 5555 RTP/AVP 97 

c=IN IP6 3333 :: aaa :bbb : ccc :ddd 

a=rtpmap:97 PCMU/90000 

m=video 3000 RTP/AVP 98 

c=IN IP6 4444 :: aaa :bbb : ccc : ddd 

a=rtpmap:98 MPV/90000 



4. SIP re-INVITE request (intermediate IM CN subsystem entities to controller UE, UE-1) 

5. SIP 200 (OK) response (controller UE, UE-1 to intermediate IM CN subsystem entities) - see example in 
table A.14.4-5 

In this case, the controller UE does not want to add this media on itself, but like to delete this media within the 
collaborative session. The controller UE cknowledges the SIP re-INVITE request by sending SIP 200 (OK) 
response to the SCC AS with the port number set to zero for this media. 

Table A.14.4-5: SIP 200 (OK) (controller UE to SCC AS) 



SIP/2.0 200 OK 
Via : 
From : 
To : 

Call-ID: 
Cseq : 

Contact: <sip: userl_publicl@homel . net> ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 

0a0c43 t 6br4> ; +g . 3gpp . iut -controller 
Allow : 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 5 5 5 5 : : aaa : bbb : : ccc : ddd 
s = - 

c=IN IP6 5555 :: aaa :bbb :: ccc : ddd 
t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90 



6. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
7-8.SIP ACK (SCC AS to controller UE) 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)-see example in table A.14.4-9 

The SCC AS sends a SIP re-INVITE request to update the remote leg that the media B is released. 
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Table A.14.4-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip :user3_public3@home3 . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a762-0 0a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r2 . 12 
Max- Forwards : 

Route : <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "Jake" <sip : userl_publicl@homel . net> 
Privacy: none 

From : <sip :userl_publicl@homel . net > ; tag=17182 8 
To: <sip : user3_public3@home3 . net> ; tag = 66666 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip: userl_publicl@homel . net> ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c43t6br4 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp 
ontent-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 3333 : : aaa : bbb : ccc : ddd 
s = - 
t = 

m=audio 5555 RTP/AVP 97 

c=IN IP6 3333 :: aaa : bbb : ccc : ddd 

a=rtpmap:97 PCMU/90000 

m=video RTP/AVP 98 

c=IN IP6 4444 :: aaa : bbb : ccc : ddd 

a=rtpmap:98 MPV/90000 



10. SIP re-INVITE request (intermediate IM CN subsystem entities to remote UE) 

11. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.4-11 

The remote US sends a SIP 200 (OK) with an SDP offer containing Media A and Media B information. 
Table A.14.4-11 : SIP 200 (OK) (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: 

To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact: <sip: user3_public3@home3 . net> ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c67t6br4 > 
Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 5 5 5 5 : : aaa : bbb : : ccc : ddd 
s = - 

c = IN IP6 5555: : aaa: bbb: : ccc: ddd 
t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 
a=rtpmap:98 MPV/90 



12. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
13-14. SIP 200 (OK) response (SCC AS to UE-2 through IM CN subsystem entities) 

The SCC AS sends a 200 (OK) response. 
15-16. SIP ACK request (controllee UE to SCC AS) 
17-18. SIP ACK request (SCC AS to remote UE) 
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A. 14.5 Controllee UE modifies media on itself 



Media-A between UE-1 and Remote UE- 




SCCAS 



Media-B between UE-2 and Remote UE- 



2. re-INVITE_ 
Media-B 

3. re-INVITE 
c=UE-1 
Media-A - 
c=UE-2 
Media-B 



4. re-INVITE 
c=UE-1 

— Media-A — 
c=UE-2 
Media-B 

5. 200 (OK) 
_c=Remote UE_ 

Media-A 
Media-B 



6. 200 (OK) 
c=Remote UE 
Media-A 
Media-B 

7. ACK 



9. 200 (OK) 
c=Remote UE- 
Media-B 



-8. ACK- 



12. ACK- 



Media-A between UE-1 and Remote UE- 



Media-B between UE-2 and Remote UE- 



Remote UE 



Figure A.14.5: Controllee UE modifies media on itself 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with voice (Media A) and UE-2 with video (Media B) media flows. Subsequently, the UE-2 (Controllee 
UE) modifies the media B flow that is active on the remote UE. 

1. SIP re-INVITE request (UE-2 to intermediate IM CN subsystem entities)- see example in table A.14.5-1 

UE-2 sends a SIP re-INVITE request towards the remote UE containing Media B using SDP offer. 
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Table A.14.5-1 : SIP re-INVITE request (UE-2 to intermediate IM CN subsystem entities) 



INVITE <sip :userR_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via : SIP/2 . 0/UDP [4444: : aaa : bbb : ccc : ddd] : 13 57 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . visitedl . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 1 . homel . net ; lr> 

P-Asserted- Identity : "John Doe2" <sip : userl_public2@homel . net> 

P-Access-Network-Inf o : 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: 

To: Call-ID: 
Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 
c=8G42; port-s=7531 

Contact: <sip: userl_public@homel . net> ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a765 - 

00a0cG7t6br4>Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, 
NOTIFY 

Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 4444 :: aaa : bbb : ccc : ddd 
s = - 

c=IN IP6 4444 :: aaa : bbb : ccc : ddd 
t = 

m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



2. SIP re-INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the SCC AS according to 
standard IMS procedure. 

3. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.14.5- 

3 

The SCC AS sends a SIP re-INVITE request to the remote UE through the intermediate IM CN subsystem 
entities containing Media A and Media B information in SDP offer. 
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Table A.14.5-3: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip : userR_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl .homel . net ;branch=z9hG4bK240a48 . 12 
Max- Forwards : 70 
Route : 

P- Asserted- Identity : 
P-Access-Network-Info : 
Privacy : 
From : 
To : 

Call-ID: 
Cseq : 
Require : 
Proxy-Require : 
Supported : 
Security- Verify : 
Contact : 
Allow : 
Accept : 
Content-Type : 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 3 3 3 3 : : aaa : bbb : ccc : ddd 
s = - 
t = 

m=audio 2222 RTP/AVP 97 

c = IN IP6 3333 : :aaa:bbb:ccc:ddda=rtpmap:97 MPV/90000 

m=video 4444 RTP/AVP 98 

c=IN IP6 4444 :: aaa : bbb : ccc : ddd 

a=rtpmap:98 MPV/90000 



4. SIP re-INVITE request (intermedia IM CN subsystem entities to remote UE) 

5. SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) - see example in 
table A.14.5-5 

The remote EU sends a an SIP 200 (OK) response with SDP answer. 
Table A.14.5-5: SIP 200 (OK) response (remote UE to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ; branch=z9hG4bK240f 26 . 3 , SIP/2. 0/UDP 
scscf 2 .homel .net ;branch=z9hG4bK332d2 5 . 1 , SIP/2 . 0/UDP 
scscfl .homel .net ;branch=z9hG4bK33 2d2 5 . 2 , SIP/2 . 0/UDP 
sccasl .homel .net ;branch=z9hG4bK240a48 . 12 

From: 

To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 5 5 5 5 :: aaa : bbb : ccc : ddd 
s = - 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio 4444 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



6. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

7-8. SIP ACK request (SCC AS to the remote UE through intermediate IM CN subsystem entities) 
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The SCC AS sends an SIP ACK request to the remote UE through the intermediate IM CN subsystem entities. 

9. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.14.5- 
9 

The SCC AS sends a SIP 200 (OK) response containing Media B information and send it to UE-2 through the 
intermediate IM CN subsystem entities. 

Table A.1 4.5-9 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP sccasl.homel.net;branch=z9hG4bK240f42.22, 

From : 

To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 5 5 5 5 : : aaa : bbb : ccc : ddd 
s = - 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



10. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-2) 

11-12. SIP ACK request (UE-2 to SCC AS through intermediate IM CN subsystem entities) 

UE-2 sends a SIP ACK request to the intermediate IM CN subsystem entities which is terminated by the SCC 
AS. 



A.1 4.6 Remote UE adds new media on controllee UE 

It is assumed that UE-1 is the controller UE having collaborative session control. A user has a multimedia session on his 
device UE-1 with voice (Media A) and video (Media B) media flows. Subsequently, the remote UE adds the media B 
flow. In this scenario it is assumed that the controller UE, UE-1 automatically initiates the addition of the new media on 
UE-2 (Controllee) without first alerting the user and sends a SIP REFER request prior to sending back a SIP 200 (OK) 
response to the SIP re-INVITE request. 
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Figure A.14.6: Remote UE add new media on Controllee UE 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SIP re-INVITE request (remote UE to intermediate IM CN subsystem entities) - see example in table 
A.14.6-1 
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The remote UE sends a SIP re-INVITE request towards the controller UE (UE-1) indicating media B is to be 
added in SDP offer. 

Table A.14.6-1 : SIP re-INVITE request (remote UE to intermediate IM CN subsystem entities) 



INVITE <sip :userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 2 . visited2 . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 2 . homel . net ; lr> 

P-Asserted- Identity : "David Fan" <sip : user3_public3@home3 . net > 

P-Access-Network-Info : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 
c=8G42; port-s=7531 

Contact : <sip : user3_public3@home3 . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a76 5 - 0a0c6 7t6br4 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = - 

c=IN IP6 5555 :: aaa :bbb : ccc : ddd 
t = 

m=audio 6666 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



2-4. SIP re-INVITE request 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to UE-1 via the SCC AS according 
to standard IMS procedure. 

5-6. SIP REFER request (UE-1 to SCC AS through intermediate IM CN subsystem entities) - see example 
in table A.14.6-5 

The controller UE determines to add the new media (Media B) on the controllee UE. The controller UE, UE-1 
sends a SIP REFER request to the SCC AS containing a Refer-To header field containing the GRUU of 
controllee UE, UE-2 and a body parameter containing an m line for audio set to and an m line for video with 
the port number set to the port number of the video media line from the SDP offer in the SIP re-INVITE request 
from the remote UE. The SIP REFER request also includes a Target-dialog header field containing the details of 
the dialog for the existing session between the controller UE, UE-1 and the remote UE. 
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Table A.1 4.6-5 SIP REFER request (UE-1 to SCC AS) 



REFER sip : interUEtransf er@sccasl . homel . net SIP/2.0 
Via : 

To : sip : interUEtransf er@sccasl . homel . net 

From : sip : userl_publicl@homel . net ; tag=34 719 

Call -ID: Cb0 3a0s09a2sdfglkj 490333 

CSeq: 93809824 REFER 

Max-Forwards: 70 

P- Preferred- Identity : 

Ref er-To : <sip : userl_public2@home2 . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

00a0c91e6bf e?body=m%3Daudio%2 00%2 0RTP%2FAVP%2 097%0Dm%3Dvideo%2 04444%2 0RTP%2FAVP%2098> 
Require: target-dialog 

Target -dialog: cb0 3a0s0 9a2sdf glkj 490333 ; remote- tag=13579 ; local- tag=24680 
Ref erred-By : sip : userl_publicl@homel . net 

Contact : <sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a76 5- 

0a0c91e6bf 6> ; +g . 3gpp . iut- controller 
Allow : 

Accept : message/sipf rag 
Content-Length: 



7-8. SIP 202 (Accepted) response 

The SCC- AS sends a SIP 202 (Accepted) response to the controller UE-1 as response to the SIP REFER request. 

9-10. SIP NOTIFY request (SCC AS to UE-1 through intermediate IM CN subsystem entities)-see example 
in table A.14.3.2-5 

The SCC AS sends a SIP NOTIFY request to UE-1 to notify implicit subscription to the SIP REFER request 
results. 

Table A.14.3.2-5 SIP NOTIFY request (SCC-AS to UE-1) 



NOTIFY sip :userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 SIP/2.0 
Via : 

To : sip : userl_publicl@homel . net ; tag=34 719 

From : sip : interUEtransf erOsccasl . homel . net ; tag=22 5 5 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity: 

Require : 

Contact : <sip : user3_public3@home3 . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c67t6br4 > 
Allow : 

Event : refer 

Subscript ion- St ate : active ; expires=3 6 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 100 Trying 



11-12. SIP 200 (OK) response (UE-1 to SCC-AS through intermediate IM CN subsystem entities) 

The controller UE, UE-1, acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to SCC 
AS. 

13-14. SIP 200 (OK) response (UE-1 to SCC-AS through intermediate IM CN subsystem entities)-see example 
in table A.14.6-13 

The controller UE responds to the SIP re-INVITE request in step 4. 
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Table A.14.6-13: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 3 , SIP/2. 0/UDP 
scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1 , SIP/2 .0/UDP 
sccasl . homel . net ; branch=z9hG4bKnas34r4 . 12 

From: 

To : 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : 

Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 3 3 3 3 : : aaa : bbb : ccc : ddd 

B=- 

c = IN IP6 3333: : ccc: ddd: aaa: bbb 
t = 

m=audio 8888 RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video RTP/AVP 98 



15-16. SIP ACK (SCC AS to UE-1 through intermediate IM CN subsystem entities) 

17. SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)-see example in table A.14.6-15 

NOTE 2: This SIP INVITE request can be sent as soon as the SIP REFER request is received. 

The SCC AS sends a SIP INVITE request towards UE-2 through the intermediate IM CN subsystem entities 
indicating Media B information in SDP offer. 

Table A.14.6-17: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip : userl_public2@homel . net ; gr=urn : uuid : 2ad8 92 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r2 . 12 
Max-Forwards: 70 

Route : <sip : termOscscf 1 . homel . net ; lr> , <sip : pcscf 1 .visitedl . net : 75 3 8 ; lr ; comp=sigcomp> 
P-Asserted-Identity : "John Doe" <sip : user3_public3@home3 . net > 
Privacy: none 

From: <sip : user3_public3@home3 . net> ; tag=17182 8 
To : <sip :userl_public2@homel . net> 
Call- ID: Cb03a0s09a2sdfglkj4903 3 3 
Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Ref erred-By : sip : userl_publicl@homel . net 

Contact : <sip : user3_public3@home3 . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c67t6br4 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE , SUBSCRIBE, NOTIFY 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5 5 5 5 :: aaa : bbb : ccc : ddd 
s = - 

c=IN IP6 4444 :: bbb : aaa : ccc : ddd 
t = 

m=audio RTP/AVP 97 
m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



18. SIP INVITE request (intermediate IM CN subsystem entities to UE-2) 

19. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 

UE-2 responds with a SIP 200 (OK) response containing the SDP answer. 



- see example in table A.14.6-19 
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Table A.14.6-19: SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 3 , SIP/2. 0/UDP 

scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1 , SIP/2 .0/UDP 

sccasl . homel . net ; branch=z9hG4bKnas34r2 . 12 
From: 

To : <sip : userl_public2@homel . net > ; tag=237674 
Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : <sip : userl_public2@homel . net ;gr=urn : uuid : 2ad892 0e-4 8a5-4a74-8d99- 
ad76cc7f c74> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " 
Allow : 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933300 2987933300 IN IP6 4444 : : aaa : bbb : ccc : ddd 
s = - 

c=IN IP6 4444 :: aaa : bbb : ccc : ddd 
t = 

m=audio RTP/AVP 97 
m=video 6666 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



20. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
21-22. SIP ACK (SCC AS to UE-2 through intermediate IM CN subsystem entities) 

23. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.14.6- 
23 

In response to the SIP re-INVITE from the remote UE, the SCC AS sends a SIP 200 (OK) response containing 
the SDP answer towards the remote UE through IM CN subsystem entities, which includes Media A and Media 
B information. 

Table A.14.6-23: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG6bKnas34r4 , SIP/2. 0/UDP 
scscf 2 . visited2 .net ;branch=34qtrada3333 .22 , SIP/2 . 0/UDP 
pcscf 2 . visited2 .net ; branch=34qtrada5454 . 12 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 
Contact : 
Allow : 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 :: aaa : bbb : ccc : ddd 
s = - 
t = 

m=audio 8888 RTP/AVP 97 

c = IN IP6 3333: : ccc: ddd: aaa: bbb 

a=rtpmap:97 PCMU/8000 

m=video 6666 RTP/AVP 98 

c=IN IP6 4444 :: bbb : aaa : ccc : ddd 

a=rtpmap:98 MPV/90000 



24. SIP 200 (OK) response (intermediate IM CN subsystem entities to remote UE) 
25-26. SIP ACK (remote UE to SCC AS through intermediate IM CN subsystem entities) 
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The remote UEsends a SIP ACK request to the intermediate IM CN subsystem entities which terminated by the 
SCC AS. 

27-28. SIP NOTIFY request (from SCC AS to controller UE, UE-1) 

The SCC AS sends a SIP NOTIFY request to the controller UE, UE-1 to inform about the success status if the 
inter-UE transfer. 

Table A.14.6-27: SIP NOTIFY request (SCC AS to UE-1) 



NOTIFY sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 SIP/2.0 
Via: 

To : sip :userl_publicl@homel . net ; tag=34 719 

From : sip : interUEtransf erOsccasl . homel . net ; tag=22 5 5 

Call-ID: 

CSeq: 

Max- Forwards : 

P- Asserted- Identity : 

Require : 

Contact : <sip : user3_public3@home3 . net ;gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c67t6br4 > 
Allow: 

Event : refer 

Subscription-State : terminated; reason=noresource 
Content-Type : message/sipf rag; version=2 . 
Content-Length: (...) 

SIP/2.0 200 OK 

Content-Type: application/sdp 

v=0 
s = - 

m=audio RTP/AVP 97 
m=video 6666 RTP/AVP 98 



29-30. SIP 200 (OK) response (from controller UE to SCC AS) 

The controller UE acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to the SCC AS. 
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A. 14.7 Remote UE releases media on the controller UE 




Intermediate IM 
CN entities 



SCC AS 



Collabarative session control 1 

■ 

Media-A between UE-1 and Remote UE- 



4. re-INVITE 
c= Re mote UE- 
Media-A=0 



5. 200 (OK) 
- c=UE-1 - 
Media-A=0 



Media-B between UE-1 and Remote UE — 

1. re-INVITE 

. c= Re mote UE_ 

' Media-A=0 
Media-B 

2. re-INVITE 
_c=Remote UE 

Media-A=0 
Media-B 

3. re-INVITE 
I— c= Remote UE— 

Media-A=0 



■8. ACK- 



6. 200 (OK) 
- c=UE-1 - 
Media-A=0 

— 7. ACK — 

9. 200 (OK) 

c=UE-1 
-Media-A=0- 
c=UE-2 
Media-B 



10.200 (OK) 

c=UE-1 
- Media-=0 - 
c=UE-2 
Media-B 



-11. Ack- 



-12. Ack- 



■Collabarative session control- 



i 

-Media-B between UE-2 and Remote UE- 



Remote UE 



Figure A.14.7: Remote UE releases media on the controller UE 



NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SIP re-INVITE request (Remote Party to intermediate IM CN subsystem entities) - see example in 
table A.14.7-1 

The remote UE sends a SIP re-INVITE request towards the controller UE (UE-1) indicating Media A is to be 
removed using SDP offer. If Media B is to be removed, the SIP re-INVITE request will send to controllee UE 
(UE-2). 
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Table A.1 4.7-1 : SIP re-INVITE request (Remote UE to intermediate IM CN subsystem entities) 



INVITE <sip :Userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 13 57 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 2 . visited2 . net : 7531 ; lr ; comp=sigcomp> , <sip : origOscscf 2 . homel . net ; lr> 

P-Asserted- Identity : "David Fan" <sip : userR_publicl@homel . net > 

P-Access-Network-Inf o : 3GPP-UTRAN-TDD ; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From : 

To : 

Call-ID: 

Cseq: 127 INVITE 
Require: sec-agree 
Proxy-Require: sec-agree 
Supported: lOOrel, precondition 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi- s=87654321 ; port- 
c=8S42; port-s=7531 

Contact: <sip: userl_public@homel . net> ; gr=urn : uuid : f 81d4f ae- 7dec- Ild0-a765- 00a0c67t6br4 > 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp , application/3gpp- ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = - 

c=IN IP6 5555 :: aaa :bbb : ccc : ddd 
t = 

m=audio RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 4444 RTP/AVP 98 
a=rtpmap:98 MPV/90000 



2. SIP re-INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the re-INVITE request to the SCC AS according to standard 
IMS procedures. 

3. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.14.7- 

3 

The SCC AS removes the Media B information and forwards it towards intermediate IM CN subsystem entities. 
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Table A.14.7-3: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE <sip :userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6> SIP/2.0 
Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r4 . 12 
Max-Forwards: 70 

Route : <sip : termOscscf 2 . homel . net ; lr> 
P- Asserted- Identity : 
P-Access-Network-Info : 
Privacy : 
From : 
To : 

Call-ID: 
Cseq : 

Supported : 
Require : 
Proxy-Require : 
Security-Verify : 
Contact : 
Allow : 
Accept : 
Content-Type : 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 
s = 

c = IN IP6 5555: : aaa: bbb: ccc : ddd 
t = 

m=audio RTP/AVP 97 
a=rtpmap: 97 PCMU/8000 



4. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the controller UE according to 
standard IMS procedure. 

5. SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) - see example in table A.14.7-5 

UE-1 sends a SIP 200 (OK) response with an SDP answer. 

Table A.14.7-5: SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 3 , SIP/2. 0/UDP 

scscfl .homel .net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 0/UDP 

sccasl . homel . net ; branch=z9hG4bKnas34r4 . 12 
From : 
To: 

Call-ID: 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5- 

0a0c91e6bf 6> ; +g . 3gpp . iut- controller 
Allow: 

Accept: application/sdp; 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 :: eee : fff : aaa :bbb 
s = - 

c = IN IP6 3333 : :eee:fff :aaa:bbb 
t = 

m=audio RTP/AVP 97 
a=rtpmap:97 PCMU/8000 



6. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 
7-8. SIP ACK (SCC AS to UE-1 through intermediate IM CN subsystem entities) 

The SCC AS sends a SIP ACK request to the controller UE through the intermediate IM CN subsystem entities. 
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9. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) - see example in table A.14.7- 
9 

The SCC AS sends a SIP 200 (OK) response with an SDP answer indicating Media A is removed to the 
intermediate IM CN subsystem entities 

Table A.14.7-9: SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG6bKnas34r4 , SIP/2. 0/UDP 
scsf 2 . visited2 . net ; branch=3q5qef sdr62233 . 22 , SIP/2 . 0/UDP 
pcscf2 .visited2 . net ; branch=3q5qef sdr62245 . 12 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 

From: 

To : 

Call-ID: 

Cseq: 12 7 INVITE 

Supported: lOOrel; precondition 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5- 

0a0c91e6bf 6> ; +g . 3gpp . iut- controller 
Allow: 

Accept: application/sdp; 
Content-Type : application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IP6 3333 :: aaa : bbb : ccc : ddd 
s=- 

c=IN IP6 3333 :: aaa :bbb : ccc :ddd 
t = 

m=audio RTP/AVP 97 
a=rtpmap:97 PCMU/8000 
m=video 6666 RTP/AVP 98 
c=IN IP6 4444 :: aaa: bbb: ccc: ddd 
a=rtpmap:98 MPV/90000 



10. SIP 200 (OK) response (intermediate IM CN subsystem entities to remote UE) 

11-12. SIP ACK (remote UE to SCC AS through intermediate IM CN subsystem entities) 

The remote UE sends a SIP ACK request to UE-1 through the intermediate IM CN subsystem entities which is 
terminated by the SCC AS. 

Editor's Note: The SDP in this flow is FFS. 



A.1 5 Signalling flows for MSC server assisted mid-call 
feature 

A.1 5.1 Introduction 

The signalling flows in the subclause demonstrate how full duplex session on hold can be transferred together with 
active full duplex session when the MSC server assisted mid-call feature is used. The following signalling flows are 
included: 

subclause A.15.2 shows an example of CS to PS access transfer with the MSC server assisted mid-call feature, 
subclause A. 15.3 shows an example of PS to CS access transfer with the MSC server assisted mid-call feature. 
The examples assume that: 

- the SC UE, the MSC Server enhanced for ICS and the SCC AS support the MSC server assisted mid-call feature; 
the SC UE does not use ICS procedures; and 

the SCC AS is allowed to use the MSC Server assisted mid-call feature according to operator policy. 
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A. 15.2 CS to PS access transfer with MSC server assisted mid-call 
feature 

In the example flow at the figure A. 15. 2-1, SC UE A has two ongoing sessions over CS bearer which are anchored at 
SCC AS. The active session X is with UE B, the held session Y is with UE C. The session X and session Y are two 
party sessions. The session Y contains rejected video stream and accepted audio stream. When the SC UE connects to 
an IP-CAN, it decides to transfer the sessions over the IP -CAN. 
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Figure A.15.2-1 : Signalling flow for PS-CS Access Transfer: CS to PS 
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NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A has an ongoing active session X with remote UE B and a held session Y with remote UE C 
The calls have been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 

2. SC UE A connects to a new IP-CAN: 

The SC UE A decides to transfer the sessions over the new IP -CAN. The UE A obtains an IP address that it will 
use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using standard registration 
procedure and reserves resources in the new IP-CAN. 

3. SIP INVITE request transferring the active session X (SC UE A to intermediate IM CN subsystem 
entities) - see example in table A.15.2-3 

The SC UE A sends an initial SIP INVITE request to request the new call replaces the existing call X. 
Table A.15.2-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : domain. xferOsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max- Forwards : 70 

Route : <sip : pcscf 1 . homel . net : 7531 ; lr> , <sip: origOscscf 1 . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net> 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <sip : userl_publicl@homel . net > ; tag=171828 

To: <tel : +l-237-555-2222> 

Call -ID : Cb03a0s09a2sdfglkj4 902 3 7 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu, norefersub 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91e6bf 6> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " ; +g . 3gpp . mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp ; application/3gpp- ims+xml , application/vnd . 3gpp . mid-call+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = 

c=IN IP6 5555 :: aaa :bbb : ccc : ddd 
t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 



Contact: contains the g.3gpp. mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

Accept: contains the MSC Server assisted mid-call feature MIME type. 

4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 
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The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re -INVITE request towards the Remote Leg. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. The SIP re-INVITE request 
contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE 
request from the UE A (Step 3). 

8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate EVI CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The media path of session X is using the new IP -CAN but the media path of the session Y is still using the CS 
bearer. 

18-19. SIP BYE request (SCC AS to MSC Server via intermediate EVI CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request. 

20-22. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS 
bearer. 

23-24. SIP 200 (OK) response (MSC Server to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the MSC Server sends a SIP 200 (OK) response over 
the old IP-CAN to the SCC AS. 

25: SIP REFER request (SCC AS to Intermediate IM CN subsystem entities) -see example in table A.15.2-25 

The SCC AS sends SIP REFER request towards UE A inside the dialog created by the message 13. 
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Table A.15.2-25: SIP REFER request (SCC AS to IM CN subsystem entities) 



REFER sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91e6bf 6 SIP/2.0 
Via: SIP/2. 0/UDP sip : sccasl . homel . net ; branch=z9hG4bk73 lb8a 
Max-Forwards: 70 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 

From: <tel : +1-237- 555 -2222 > ; tag=aasdf gaag 

To: <sip : userl_publicl@homel . net> ; tag=171828 

Call -ID: Cb03a0s09a2sdfglkj 490237 

Cseq: 55998 REFER 

Content-Length: . . . 

Route : <sip:scscfl. homel . net ; lr> , <sip :pcscf 1 . homel .net : 7531 ; lr> 

Contact : <sip : sccasl . homel . net ; gr> 

Refer-Sub: false 

Supported: norefersub, gruu 

Ref er-To : <sip : additional . session . xf erOsccas . homel . net ?Target-Dialog=a84b4c76e6 6 710 %3Bremote- 
tag=654364735%3Blocal-tag=19283 01774&Require=tdialog&From=tel : +l-23 7-555-llll&To=tel : +1- 
987-654-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D- 
%2 02 987933 62 3%2 02 987 93362 3%2 0IN%2 0IP6%2 05555 : : ggg : f f f : aaa : bbb%0D%0As%3D- 

%0D%0Ac%3DIN%2 0IP6%2 05555 : : ggg : f f f : aaa : bbb%0D%0At%3D0%2 00%0D%0Am%3Dvideo%2 00%2 0RTP%2FAVP%2 
98%0D%0Am%3Daudio%2 03456%2 0RTP%2FAVP%2 97%2 096%0D%0Ab%3DAS : 25 . 4%0D%0Aa%3Drtpmap : 97%2 0AMR%0D 
%0Aa%3Dfmtp: 97%2 0mode- set%3D0%2C2%2C5%2C7%3B%2 0mode- change - 
period%3D2%0D%0Aa%3Dmaxptime : 20%0D%0A> 
Content -Type : application/vnd . 3gpp . mid-call+xml 

<?xml version=" 1 . 0" encoding= "UTF- 8 " ? > 
<mid-call/> 



Refer-To: contains the additional transferred session SCC AS URI and the following URI header fields: 
Target-Dialog: the dialog identifier of the source access leg. 
Require: containing "tdialog" option tag 
From: contains the public user identity of the UE A 
To: contains the public user identity of the UE C 

Content-Type: containing "application/sdp" MIME type of the "body" URI header field 

body: SDP describing the media used in the session 

26. SIP REFER request (intermediate IM CN subsystem entities to UE A) 

The SIP REFER request is forwarded towards the UE A. 

27-28. SIP 202 (Accepted) response (UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP REFER request, the UE A sends a SIP 202 (Accepted) response. 

29. SIP INVITE request transferring the held session Y (SC UE A to intermediate IM CN subsystem entities) 
- see example in table A.15.2-29 

The SC UE A sends an initial SIP INVITE request to request the new call replacing the existing call Y. 
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Table A.15.2-29: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : additional . session . xferSsccas . homel . net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip : pcscf 1 . homel . net : 7531 ; lr> , <sip: origOscscf 1 . homel . net ; lr> 
P-Pref erred- Identity : "John Doe" <sip : userl_publicl@homel . net > 
P-Access-Network-Info : IEEE-802 . lib 
Privacy: none 

From: <tel : +1-237- 555 - 1111> ; tag=171828 
To: <tel : +l-987-654-3210> 
Call-ID: asdfqweasas 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; portl=7531 
Contact : <sip : userl_publicl@homel . net ; gr=urn :uuid : f 81d4f ae- 7dec- lldO -a76 5 - 

0a0c91eGbf G> ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7 %3gpp- service . ims . icsi . mmtel " ; +g . 3gpp . mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp ; application/3gpp- ims+xml 

Target -Dialog: a84b4c76e6 6 710 ; remote-tag=6 54 3 64 73 5 ; local- tag=19283 01774 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = 

c = IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=video RTP/AVP 98 

m=audio 3456 RTP/AVP 97 96 

b=AS : 25 . 4 

a=curr:qos loca 

a=tcap : 1 RTP/AVPF 

a=pcfg:l t=ll sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 
a=sendonly 



Request-URI: contains the additional transferred session SCC AS URI as received in the Refer-To URI in the 
SIP REFER request. 

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the SIP REFER request. 

Contact: contains the g.3gpp. mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

SDP: All the media are offered with the sendonly directionality. 

30. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

31. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

32. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

33. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID header fields from one side of the B2BUA to the other. The SIP re-INVITE request 
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contains the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE 
request from the UE A. 

34. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE C) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE C. 
35-36: SIP 200 (OK) response (UE C to SCC AS via Intermediate IM CN subsystem entities) 

The UE C generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
37-38: SIP ACK request (SCC AS to UE C via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE C. 
39: SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
40: SIP 200 (OK) response (Intermediate IM CN subsystem entities to UE A) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
41-42: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 
43. Media paths between UE A and UE B 

The media paths of session X and session Y are using the new IP -CAN but the the CS bearer is still not released. 
44-45. SIP BYE request (SCC AS to MSC Server via intermediate EVI CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a SIP BYE request. 

46-48. CC DISCONNECT message (interworking entities to SC UE A) 

Upon receiving the CC DISCONNECT message, the SC UE A relinquishes all resources pertaining to the CS 
bearer. 

49-50. SIP 200 (OK) response (MSC Server to SCC AS via intermediate IM CN subsystem entities) 
51. Media paths between UE A and UE B 

The media paths of session X and session Y are using the new IP-CAN. 

A.1 5.3 PS to CS access transfer with MSC server assisted mid-call 
feature 

In the example flow at the figure A.15.3-1, SC UE A has two ongoing sessions over PS bearer which are anchored at 
SCC AS. When both sessions were established the SC UE and the SCC AS included the g.3gpp. mid-call media feature 
tag as specified in annex C into the Contact header fields. The active session X is with UE B, the held session Y is with 
UE C. The session X and session Y are two party sessions. The session Y contains a rejected video stream and an 
accepted audio stream. When the SC UE attaches to the CS domain, it decides to transfer the sessions over the CS 
bearer without using the ICS capability. 
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Figure A.15.3-1 : Signalling flow for PS-CS access transfer: PS-CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A is on an active session X with UE B and a held session Y with UE C: 

There is an ongoing IP bearer between the SC UE and the remote UE B and another IP bearer between the SC 
UE and the remote UE C. Both sessions are anchored at SCC AS. 

2. SC UE A attaches to the CS domain 

The SC UE attaches to the CS domain and decides to transfer the sessions over the CS bearer. 

3. CC SETUP messages 
Transaction Identifier: 3 
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4. SIP INVITE request transferring the active session X (MSC Server to Intermediate IM CN subsystem 
entities) -see example in table A.15.3-4 

Upon receiving the CC SETUP message the MSC Server sends a SIP INVITE request and associates the 
transaction identifier 3 with the SIP INVITE request. 

Table A.15.3-4: SIP INVITE request (MSC Server to intermediate IM CN subsystem entities) 



INVITE tel : +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl . homel . net ;branch=z9hG4bk731b87 
Max-Forwards: 70 

P- Asserted- Identity : <tel : +1-23 7-555 -1111> 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel : +1-23 7- 555 - 1111 > ; tag=17182 8 
To: <tel : +l-237-555-3333> 
Call- ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu, 199, norefersub 

Accept -Contact : * ; +g . 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : userl_publicl@homel . net ;gr=urn : uuid : f 81d4f ae-7dec-lld0-a76 5- 

0a0c91e6bf G> ; +g . 3gpp . icsi-ref ="urn%3Aurn- 7 %3gpp- 

service . ims .icsi .mmtel " ; +g . 3gpp . ics=" server" ; +g . 3gpp . mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

Accept: application/sdp; application/3gpp- ims+xml , application/vnd . 3gpp . mid-call+xml 
Recv-Info: g . 3gpp . mid-call 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = 

c=IN IP6 5555 :: aaa : bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone -event 
a=maxptime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MSC Server. 

Contact: contains the g.3gpp. mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

Accept: contains the MSC Server assisted mid-call feature MIME type. 

5. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

7. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re -INVITE request towards the Remote Leg. 

8. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 
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The SCC AS acting as a routing B2BUA generates a SIP re-INVITE request based upon the received SIP 
INVITE request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 

9. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

10. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

11. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

12-13. SIP ACK request (SCC AS to UE B via EVI CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

14-15. SIP 200 (OK) response (SCC AS to MSC Server via EVI CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the MSC Server. 

16. CC CONNECT message (MSC Server to SC UE A) 

17. CC CONNECT ACKNOWLEDGEMENT message (SC UE A to MSC Server) 

18-19. SIP ACK request (MSC Server to SCC AS via EVI CN subsystem entities) 

The MSC Server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS. 
20. Media paths between SC UE A and UE B: 

The CS bearer is setup while the PS bearers are still existing. 

21-22: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg of the session X, which was using the old IP-CAN, by sending a 
SIP BYE request to the UE A. 

23-24. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

25. Media paths between SC UE A and UE B 

The session X is transferred from PS bearer to CS bearer, but the session Y is still at the PS bearer. 

26. SIP REFER request (SCC AS to IM CN subsystem entities) -see example in table A.15.3-26 

The SCC AS sends SIP REFER request towards MSC Server inside the dialog created by the the message 14. 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 210 ETSI TS 124 237 V9.4.0 (2010-10) 

Table A.1 5.3-26: SIP REFER request (SCC AS to IM CN subsystem entities) 



REFER sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 00a0c91e6bf 6 SIP/2.0 
Via: SIP/2. 0/UDP sip : sccasl . homel . net ; branch=z9hG4bk73 lb8a 
Max-Forwards: 70 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 

To: <tel : +1-237- 555 - 1111 > ; tag=17182 8 

From: <tel : +1-237- 555 - 3333 > ; tag=sdf sdf 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 55998 REFER 

Content-Length: 125 

Route : <sip : scscf 1 . homel . net ; lr> 

Refer-Sub: false 

Supported: norefersub, gruu 

Contact: sip : sccasl . homel . net 

Ref er-To : < additional . session . xf erOsccas . homel . net ?Target-Dialog=ksdj f hwrklf %3Bremote- 

tag=676723565%3Blocal-tag=45418454&Require=tdialog&From=tel : +l-23 7-555-llll&To=tel : +1-987 - 

654-3210&Content-Type=application%2Fsdp&body=v%3D0%0D%0Ao%3D- 

%2 02 987933 623%2 02 987933623%2 0IN%2 0IP6%2 05555 : : ggg : f f f : aaa : bbb%0D%0As%3D- 

%0D%0Ac%3DIN%2 0IP6%2 05555 : : ggg : f f f : aaa : bbb%0D%0At%3D0%2 00%0D%0Am%3Dvideo%2 00%2 0RTP%2FAVP%2 
98%0D%0Am%3Daudio%2 03456%2 0RTP%2FAVP%2 97%2 096%0D%0Ab%3DAS : 25 . 4%0D%0Aa%3Drtpmap : 97%2 0AMR%0D 
%0Aa%3Dfmtp: 97%2 0mode- set%3D0%2C2%2C5%2C7%3B%2 0mode- change - 
period%3D2%0D%0Aa%3Dmaxptime : 20%0D%0A> 
Content -Type : application/vnd . 3gpp . mid-call+xml 

<?xml version=" 1 . 0" encoding= "UTF- 8 " ? > 
<mid-call/> 



Refer-To: contains the additional transferred session SCC AS URI and the following URI header fields: 
Target-Dialog: the dialog identifier of the source access leg. 
Require: containing "tdialog" option tag 
From: contains the public user identity of the UE A 
To: contains the public user identity of the UE C 

Content-Type: containing "application/sdp" MIME type of the "body" URI header field 

body: SDP describing the media used in the session 

27. SIP REFER request (intermediate IM CN subsystem entities to MSC Server) 

The SIP REFER request is forwarded towards the MSC Server. 

28-29. SIP 202 (Accepted) response (MSC Server to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP REFER request, the MSC Server sends a SIP 202 (Accepted) response. 

30. SIP INVITE request for the held session Y (MSC Server to Intermediate IM CN subsystem entities) -see 
example in table A.15.3-30 

Upon receiving the SIP REFER request the MSC Server sends a SIP INVITE request and associates the 
transaction identifier 4 with the SIP INVITE request. 
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Table A.15.3-30: SIP INVITE request (MSC Server to intermediate IM CN subsystem entities) 



INVITE 

sip : additional . session . xf erSsccas . homel .net SIP/2.0 
Via: SIP/2. 0/UDP mscl .homel . net ; branch=z9hG4bk731b87 
Max-Forwards: 70 

P- Asserted- Identity : <tel : +1-23 7-555 -1111> 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- ioi=homel . net 
Privacy: none 

From: <tel : +1-23 7- 555 - 1111 > ; tag=17182 8 
To: <tel : +l-987-654-3210> 
Call-ID: asdfgqwerq 
Cseq: 1275 INVITE 

Supported: lOOrel, precondition, 199, gruu 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a76 5- 

00a0c91e6bf 6> ; +g . 3gpp . icsi -ref = "urn%3Aurn- 7%3gpp- 

service . ims . icsi . mmtel " ; +g . 3gpp . ics= " server" ; +g . 3gpp . mid- call 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 

Target -Dialog : ksdj f hwrklf ; remote-tag=676723565 ; local-tag=4 54184 54 
Require : tdialog 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 
s = 

c=IN IP6 5555 :: aaa : bbb : ccc : eee 
t = 

m=video RTP/AVP 98 
m=audio 3456 RTP/AVP 97 96 
a=tcap:l RTP/AVPF 
a=pcfg:l t=l 
b=AS : 25 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 
a=sendonly 



Request-URI: contains the additional transferred session SCC AS URI as received in the Refer-To URI in the 
SIP REFER request. 

Target-Dialog: contains the dialog identifier as received in the Refer-To URI in the SIP REFER request. 

Contact: contains the g.3gpp. mid-call media feature tag as defined in annex C indicating the support for the 
MSC server assisted mid-call feature. 

SDP: The SDP contains preconfigured set of codecs supported by the MSC Server. All the media are offered 
with the sendonly directionality. 

31. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

32. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

33. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re -INVITE request towards the Remote Leg. 

34. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE C via the 
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intermediate IM CN subsystem entities. The SIP re-INVITE request contains the SDP offer that is identical to 
the SDP offer that the SCC AS received in the initial SIP INVITE request from the UE A. 

35. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE C) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE C. 

36. SIP 200 (OK) response (UE C to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE C has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

37. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

38-39. SIP ACK request (SCC AS to UE C via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE C. 

40. SIP 200 (OK) response (SCC AS to IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response towards the MSC Server. 

41. SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC Server) 

Intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP INVITE request to MSC 
Server. 

42-43. SIP ACK request (MSC Server to SCC AS via EVI CN subsystem entities) 

The MSC Server generates the SIP ACK request to the SIP 200 (OK) response, and forwards it to the SCC AS. 

44. Media paths between SC UE A and UE B: 

The CS bearer and PS bearers for both the sessions are established but there is still the original IP bearer for the 
held session Y. 

45-46: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg of the session Y, which was using the old IP-CAN, by sending a 
SIP BYE request to the UE A. 

47-48. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the SC UE A sends a SIP 200 (OK) response over the 
old IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP-CAN. 

49. Media paths between SC UE A and UE B 

Both sessions X and Y are transferred from PS bearer to CS bearer. 
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A.1 6 Signalling flows for SRVCC session transfer for IMS 
emergency session 

A.1 6.1 Introduction 

The signalling flows for SRVCC session transfer for IMS emergency session demonstrate how an IMS emergency 
session is transferred from PS network to CS network using SRVCC procedure. The following signalling flow is 
included: 

- subclause A. 16.2 shows an example when a UE initiating an emergency session in IMS for the case that the UE 
is not in limited service mode ;and 

subclause A. 16.3 shows an example when the emergency session need to transfer from PS to CS using SRVCC 
procedure for the case that the UE is not in limited service mode. 

A.1 6.2 UE initiating an emergency session in IMS 

The signalling flows shown in figure A. 16.2-1 describes the UE initiating an IMS emergency session procedure for the 
case that the UE is not in limited service mode. The flow illustrates the anchoring of the session at the EATF. 
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Figure A.16.2-1 : Signalling flow for UE initiating an emergency session in IMS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
NOTE 2: For clarity, the SIP 180 (Ringing) response is not shown in the signalling flow. 
NOTE 3: For clarity, the precondition mechanism is not shown in the signalling flow. 
1. SIP INVITE request (UE A to P-CSCF) see example in table A.16.2-2 
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INVITE urn: service : sos . fire SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 13 57 ; comp=sigcomp ;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip:pcscf.visitl. net : 7531 ; lr ; comp=sigcomp> 
P- Preferred- Identity : <sip : userl_publicl@homel . net > 

P-Access-Network-Inf o : 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From : <sip :userl_publicl@homel . net > ; tag=17182 8 

To: <urn : service : sos . fire> 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 
Accept : application/sdp , application/3gpp- ims+xml 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c91e6bf 6 > 

Geolocation : <sips : 3sdef rhy2 j j 7@lis . atlanta . example . com> ; insert ed- 

by= " sip : userl_publicl@homel .net" ; routing-allowed= "yes " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = 

c= IN IP6 5555: : aaa: bbb: ccc: ddd 
t = 

m=audio 34 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des : qos mandatory local sendrcv 

a=des: qos mandatory remote sendrcv 

a=inactive 



Contact: contains the "gr" parameter formed from an IMEI URN as specified in 3GPP TS 24.229 [2] 
2. SIP INVITE request (EATF to E-CSCF) see example in table A.16.2-3 
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INVITE urn: service : sos . fire SIP/2.0 

Via: SIP/2. 0/UDP pcscf . visitl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : <sip:ecscf. visitl. net ; lr ; > 
Record- Route : <sip: pcscf. visitl. net ; lr> 
P- Preferred- Identity : 
P-Access-Network-Info : 
Privacy : 
From : 
To : 

Call-ID: 
Cseq : 

Supported : 
Accept : 
Require : 
Proxy-Require : 
Accept-Contact : 
P-Pref erred-Service : 
Security-Verify : 
Contact : 
Geolocation : 
Allow : 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s = 
c = 
t= 
m= 

a=curr : 
a=curr : 
a=des : 
a=des : 
a= 



3. SIP INVITE request (E-CSCF to EATF) see example in table A.16.2-4 
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INVITE urn : service : sos . fire SIP/2.0 

Via: SIP/2. 0/UDP esccas .visitl . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
pcscf . visitl .net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route : <sip:esccas. visitl. net ; lr ; > 

Record- Route : <sip:ecscf. visitl. net ;lr>,<sip: pcscf. visitl. net ; lr> 

P- Preferred- Identity : 

P-Access-Network-Info : 

Privacy : 

From : 

To : 

Call-ID: 
Cseq : 

Supported : 
Accept : 
Require : 
Proxy-Require : 
Accept-Contact : 
P-Pref erred-Service : 
Security-Verify : 
Contact : 

Geolocation : <sips : 3sdef rhy2 j j 7@lis . atlanta . example . com> ; insert ed- 

by= " sip : userl_publicl@homel .net" ; rout ing-allowed= "yes " ; used- for -rout ing 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s = 
c= 
t= 

m= 
a= 
a= 
a= 
a= 
a= 



4. EATF anchors the emergency session 

The EATF (acting as a routing B2BUA) anchors the emergency session, i.e. the EATF is inserted in the 
signalling path which invokes a 3pcc for enablement of Access Transfers 

5. SIP INVITE request (EATF to E-CSCF) see example in table A.16.2-5 

The EATF acting as a routing B2BUA, generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards PSAP via the 
intermediate IM CN subsystem entities. 
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INVITE urn: service : sos . fire SIP/2.0 

Via: SIP/2. 0/UDP esccas . visitl . net ; branch=z9hG4bKnas34r5 
Max-Forwards: 67 

Route : <sip:ecscf. visitl. net : 7531 ; lr ; comp=sigcomp> 

Record- Route : <sip:ecscf. visitl. net ; lr> 

P- Preferred- Identity : <sip : userl_publicl@homel . net > 

P -Access -Network- Info : 3GPP-UTRAN-FDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 

From: <sip :userl_publicl@homel . net> ; tag=171828 

To: <urn : service : sos . fire > 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel, precondition, 199, gruu 
Accept : application/sdp , application/3gpp- ims+xml 
Require: sec-agree 
Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321 ; port=7531 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- Ild0-a765- 00a0c91e6bf 6 > 

Geolocation : <sips : 3sdef rhy2 j j 7@lis . atlanta . example . com> ; insert ed-by= " 

sip : userl_publicl@homel . net "Crouting-allowed= "yes " ; used- for -rout ing 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 
s = 

c= IN IP6 5555 :: aaa: bbb: ccc: ddd 
t = 

m=audio 34 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des : qos mandatory local sendrcv 

a=des: qos mandatory remote sendrcv 

a=inactive 



6. SIP INVITE request (E-CSCF to PSAP) 

E-CSCF routes the SIP INVITE request to the PSAP. 

7. SIP 200 (OK) response (PSAP to E-CSCF) see example in table A.16.2-6 

Table A.16.2-6: SIP 200 OK 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP ecscf . visitl . net ;branch=z9hG4bKnas34r5 
Max-Forwards: 67 

Record- Route : <sip: ecscf. visitl. net ;lr>,<sip:pcscf. visitl. net ; lr> 
Privacy: none 

From: <sip :userl_publicl@homel . net> ; tag=171828 
To: < urn : service : sos . fire > ; tag=232456 
Call-ID: 
Cseq : 

Require: lOOrel, precondition, 199, gruu 
Contact: <sip : mgcf . visitl . net > . 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 
s = 

c= IN IP6 5555 :: fff : eee : ccc :ddd 
t = 

m=audio 34 RTP/AVP 98 

a=curr: qos local none 

a=curr: qos remote none 

a=des : qos mandatory local sendrcv 

a=des : qos mandatory remote sendrcv 

a=inactive 
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8-9. SIP 200 (OK) response (E-CSCF to EATF and to E-CSCF) 

E-CSCF forwards the SIP 200 (OK) response. 
10-11. SIP 200 (OK) response (E-CSCF to UE A) see example in table A.16.2-7 

Table A.16.2-7: SIP 200 (OK) response 



SIP/2.0 200 OK 
Via : 

Max-Forwards: 65 
Record-Route : 
Privacy : 
From: 
To : 

P-Asserted-Identity : tel : 911 ; context= " +1 " 

Call-ID: 

Cseq : 

Require : 

Contact : 

Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s = 
c = 

t= 

m= 
a= 
a= 
a= 
a= 
a= 



12. SIP ACK request 

UE A responds to the 200 (OK) response with a SIP ACK request. 

A.1 6.3 Session transfer for emergency session using SRVCC 
procedure: PS-CS 

In the example in figure A. 16. 3-1, UE A (which has a valid subscription, is authenticated and authorized for PS service 
and is normal attached to the network) has an ongoing emergency session with a PSAP using a PS bearer which is 
anchored at EATF. Based upon measurement reports sent from the UE to E-UTRAN, the source E-UTRAN decides to 
trigger a SRVCC handover to CS access. 
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UE A 



Interworking 
Entities 



P-CSCF 



I-CSCF 



EATF 



E-CSCF 



1. UE A is on an emergency call with PSAP through PS network. Call is anchored at EATF. 



2. UE A sends measurement reports to 
E-UTRAN, and the source 
E-UTRAN decides to trigger an SRVCC 
handover to the UTRAN/GERAN 



-1. PS bearer- 



-3.INVITE(E-STN-SR)- 



-13. SIP 200 (OK) invite - 
14. SIP ACK 



18. SIP BYE- 
I 



-19. SIP 200 (OK)- 



•22a.CS bearer - 



4. SIP INVITE 
(E-STN-SR) * 



5 Remote leg Update 



12. SIP 
200 (OK) INVITE 



-15. SIP ACK« 



—10. SIP ACK*- 



-17. SIP BYE- 



-20. SIP 200 (OK> 



-22b. PS bearer- 



6. SIP 
relNVITE 



9. SIP 200 (OK) 

relNVITE 



-16. SIP BYE-*- 




7. SIP 
relNVITE*" 
( 8. SIP 200 _ 

(OK) relNVITE 



11. SIP ACK«- 



Figure A.1 6.3-1 Signalling flow for emergency session transfer using SRVCC procedure 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE A is on an active emergency session with a PSAP 

There is an ongoing IP bearer between the UE A and the remote end PSAP. The call is achored at EATF. 

2. SC UE A attaches to the CS domain 

UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an SRVCC 
handover to CS access. The MSC Server initiates the session transfer with the E-STN-SR, refer to 
3GPPTS 23.237 [9]. 

3. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
table A.16.3-2 
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Table A.16.3-2: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl . visitl . net ; branch=z9hG4bk731b87 
Max-Forwards: 70 

Route : <sip:icscfl. visitl. net ; lr> 

P- Asserted- Identity : <tel : +1-23 7-555 -1111> 

P- Charging- Vector : icid-value= "AyretyU0dm+602IrT5tAFrbHLso=023 551024 " ; orig- ioi=visitl . net 
Privacy: none 

From: <tel : +1-23 7- 555 - 1111 > ; tag=17182 8 
To: <tel: +l-237-555-3333> 
Call -ID: Cb03a0s09a2sdfglkj4903 34 
Cseq: 127 INVITE 

Supported: lOOrel, precondition, gruu 

Accept -Contact : * ; +g . 3gpp .icsi-ref= "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
P- Asserted- Service : urn : urn- 7 : 3gpp- service . ims . icsi . mmtel 

Contact : <sip : mscl . homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765- 00a0c91e6bf 6 > ; +g . 3gpp . icsi- 

ref = "urn%3Aurn- 7%3gpp- service . ims . icsi . mmtel " 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa : bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVP 97 96 
a=tcap : 1 RTP/AVPF 
a=pcfg:l t=l 
b=AS : 2 5 . 4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode- set=0 , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxpt ime : 2 



Request-URI: contains the E-STN-SR, as routed to the EATF 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

Contact: contains the "gr" parameter formed from an IMEI URN as specified in 3 GPP TS 24.229 [2] 

4. SIP INVITE request 

The I-CSCF routes the SIP INVITE request directly to the EATF by using the procedure defined in 
3GPP TS 23.228 [15] for PSI based application Server termination. 

NOTE 2: The use of indirect routing for PSI based Application Server Termination as described in 

3GPP TS 23.228 [15] in subclause 5.7.6 cannot be used for routing the SIP INVITE request to the EATF. 

5. Remote Leg Update 

The EATF based on the content of the "gr" parameter in the Contact header field correlates the SIP INVITE 
request to the local and remote call legs of the existing session between the UE A and the remote end. The EATF 
performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

6. SIP re-INVITE request (EATF to intermediate IM CN subsystem entities) -see example in table A.16.3-3 

TheEATF acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards PSAP via the 
intermediate IM CN subsystem entities. 

Table A.16.3-3: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 

INVITE urn : service : sos . fire SIP/2.0 

Via: SIP/2. 0/UDP esccasl . homel . net ;branch=z9hG4bKnas34r5 
Max-Forwards: 68 
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Route: <sip : ecscf 1 . homel . net : lr> 
P-Asserted-Identity : <tel: +l-237-555-llll> 

P- Charging- Function-Addresses : ccf = [5555 : :b99 : c88 : d77 : e66] ; ccf = [5555 :: a55 :b44 : c33 : d22] ; 

ecf = [5555 : : If f :2ee : 3dd:4ee] ; ecf = [5555 : : 6aa: 7bb: 8cc : 9dd] 
P -Charging- Vector : icid-value= "BzyretyU0dm+6O2IrT5tAFrbHLso=023551034 " ; orig- ioi= " type3homel .net" 
Privacy: none 

From : <sip : userl_publicl@homel . net > ; tag=17182 8 
To : <urn : service : sos . f ire> ; tag=232456 
Call- ID: Cb03a0s09a2sdfglkj 490333 
Cseq : 

Contact : <sip : userl_publicl@homel . net ; gr=urn : uuid : f 81d4f ae- 7dec- lldO -a765 - 0a0c91e6bf 6 > 
Allow: 

Content-Type: Content-Length: 
v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 
t = 

m=audio 3456 RTP/AVPF 97 96 
b=AS:25.4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap : 97 AMR 

a=fmtp:97 mode- set = , 2 , 5 , 7 ; mode-change-period=2 
a=rtpmap:96 telephone-event 
a=maxptime : 2 
m=message TCP/MSRP 98 
a=accept-types : text/plain 



7. SIP re-INVITE request (E-CSCF to PSAP) 

E-CSCF forward the SIP re-INVITE request to the PSAP. 

8. SIP 200 (OK) response (PSAP to E-CSCF) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the PSAP has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

9. SIP 200 (OK) response (E-CSCF to EATF) 

E-CSCF forward the SIP 200 (OK) response to the SIP re-INVITE request to the EATF in the originating 
network. 

10-11. SIP ACK request (EATF to PSAP via IM CN subsystem entities) 

The EATF generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request to 
the PSAP. 

12-13. SIP 200 (OK) response (EATF to interworking entities via IM CN subsystem entities) 

The E- SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 
(OK) response to the interworking entities. 

14-15. SIP ACK request (interworking entities to EATF via IM CN subsystem entities) 

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward the SIP ACK 
request to the EATF. 

16-18: SIP BYE request (EATF to UE A via intermediate IM CN subsystem entities) 

The EATF terminates the source access leg, which was using the old IP -CAN, by sending a SIP BYE request to 
the UE A. 

19-21. SIP 200 (OK) response (UE A to E- SCC AS via intermediate IM CN subsystem entities) 
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Upon receiving the SIP BYE request over the old IP -CAN, the UE A sends a SIP 200 (OK) response over the 
old IP -CAN to the EATF. Subsequently, the UE A relinquishes all resources pertaining to the old IP-CAN. 

22a. CS bearer establishment (interworking entities to UE A) 

22b. IP bearer establishment (interworking entities to PSAP) 
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Annex B (informative): 
Void 
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Annex C (normative): 

Media feature tags defined within the current document 
C.1 General 

This subclause describes the media feature tag definitions that are applicable for the 3GPP IM CN Subsystem for the 
realisation of the MSC server assisted mid-call feature and IUT transfer controller functions. 



C.2 Definition of media feature tag g.3gpp. mid-call 

Media feature-tag name: g.3gpp. mid-call 
ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: The ASN.l Identifier will need to be updated once the IANA registration is completed. 

Summary of the media feature indicated by this tag: This feature-tag when used in a SIP request or a SIP response 
indicates that the function sending the SIP message supports the MSC server assisted mid-call feature. 

Values appropriate for use with this feature-tag: none 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that a mobile phone supports the MSC server assisted mid-call feature 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [34]. 

C.3 Definition of media feature tag g.3gpp.iut-controller 

Media feature-tag name: g.3gpp.iut-controller 
ASN.l Identifier: 1.3.6.1.8.2.x 

Editor's note: The ASN.l Identifier will need to be updated once the IANA registration is completed. 

Summary of the media feature indicated by this tag: This media feature-tag when used in a SIP request or a SIP 
response indicates that the function sending the SIP message supports the IUT Controller functionality. This media 
feature tag does not imply that the controller UE capabilities are handled in the same protocol manner. 

Values appropriate for use with this feature-tag: none 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, 
such as a phone or PDA. 

Examples of typical use: Indicating that a mobile phone supports the IUT controller capability 

Related standards or documents: 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 12.1 of 
IETF RFC 3840 [34]. 
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Annex D (informative): 
XML schemas 

D.1 MSC Server assisted mid-call feature XML schema 



D.1.1 General 

This subclause defines XML schema and MIME type related to the MSC Server assisted mid-call feature. 



D.1.2 XML schema 

<?xml version= " 1 . " encoding= "UTF- 8 " ? > 
<xs : schema 

xmlns :xs = "http : //www. w3 . org/2 01/XMLSchema" 
element FormDef ault= " qualified" 
attributeFormDef ault= "unqualified" > 

<xs:element name="mid-call" type= "Tmid-call " /> 

<xs : complexType name="Tmid-call" > 
<xs : sequence> 

<xs : element name= "participant " type= "xs : anyURI " minOccurs= " " maxOccurs= "unbounded" / > 
<xs : any namespace= " ##other " processContents= " lax" minOccurs= " " maxOccurs= "unbounded" / > 
</xs : sequence> 

<xs : anyAttribute namespace= " ##any" processContents= " lax" /> 
</xs : complexType> 

</xs : schema> 

D.1 .3 IANA registration template 

Editor's note: The MIME type "application/vnd.3gpp.mid-call+xml" as defined in this subclause is to be registered 
in the IANA registry for Application Media Types based upon the following template. 

MIME media type name: 

application 

MIME subtype name: 

vnd.3gpp.mid-call+xml 

Required parameters: 

None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [21]. 

Encoding considerations: 

Same as encoding considerations of application/xml as specified in IETF RFC 3023 [21] 
Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [21]. In 
addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [19] apply. 

Interoperability considerations : 
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Same as interoperability considerations as specified in section 3.1 of IETF RFC 3023 [21]. 
Published specification: 

3GPP TS 24.237 "IP Multimedia Subsystem (IMS) Service Continuity", version 9.1.0, available via 
http://www.3gpp.org/specs/numbering.htm. 

Applications which use this media: 

Applications support the service continuity as described in the published specification. 

Intended usage: 

COMMON 

Additional information: 

1. Magic number(s): none 

2. File extension(s): none 

3. Macintosh file type code: none 

4. Object Identifiers: none 



ETSI 



3GPP TS 24.237 version 9.4.0 Release 9 



228 



ETSI TS 124 237 V9.4.0 (2010-10) 



Annex E (informative): 

INFO package for transfer of the conference information 
E.1 General 

This clause describes the info package requirements as specified in draft-ietf-sipcore-info-events [54]. 

Applicability: This package is used to transport participant identities when the PS to CS access transfer with the MSC 
Server assisted mid-call feature is applied to a session with conference focus. 

Info Package Name: g.3gpp. mid-call 

Info Package Parameters: none 

Info Package Tags: none 

INFO Bodies: application/vnd.3gpp.mid-call+xml 

UAC generation of INFO requests: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 
3" 

UAS processing of INFO requests: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 
3" 

Rate of INFO Requests: single INFO request generated after session set up 
IANA Registrations: none 

Security Considerations: the INFO requests carrying the g.3gpp. mid-call info package data need to be sent over 
transport protocol with integrity protection and confidentiality protection. 

Examples: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3" 
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Annex F (informative): 
Change history 
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